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Convergence 




^_ magine that you and your friends 
could go to the movie theater, and 
alongside your H ollywood fav- 
orites were additional movies that 
I were interactive. These I -movies 
would be similar to movies in that they 
have a narrative structure, a high-resolu- 
tion and high-fidelity presentation, and 
actors you know. But there the similarities 
end. To the side of the theater sits a guide, 
a person who plays the l-movie like a jazz 
musician plays an improvisation. The 
guide uses interactivity with the audience 
and his or her own personal whims to con- 
struct a linear narrative from the structure 
that is unique for each viewing. The partic- 
ipants get some control over the experi- 
ence, like a game, and a satisfying linear 
narrative, like a movie. 

It's been ten years since I first came across 
this concept, proposed by virtual reality pio- 
neers such asjaron Lanier. I've had it stuck 
in my mind ever since, and I subconsciously 
use it as a metric for the interactivity of 
films and games. What I'm talking about is 
a convergence of art forms, to create some- 
thing new which has an interactivity level 
somewhere between zero (movies) and lots 
(games). The l-movie would be defined less 
rigorously in a narrative sense than a tradi- 
tional movie or game, but the experience of 
it as played by the guide would be as linear 
as a movie. The guide would be someone 
who has been specially trained to deliver a 
compelling experience to the participants 
given the parameters laid out by the l-movie 
creator. Each l-movie would have a narra- 
tive direction and fundamental story line, 
but it would be open enough to allow for a 
unique experience each time. 

New Technologies 

We've all seen our fair share of 
movies with minimal (dorky) inter- 
activity, and games that have so much FM V 
they're effectively interactive movies. We 
haven't found the sweet spot yet, but this 
convergence is heading for us at full steam. 

Sony recently announced new technolo- 
gy which gives this concept a big powerup. 
They are in a unique position to promote 
real-time digital theater entertainment, 
having strong foundations in movies, 



games, and music, as well as the coffer to 
support a hefty R& D investment. This 
year at Siggraph, Sony demonstrated the 
GScube, a box resembling a Borg Cube 
that's been fitted with 16 modified Play- 
station 2 chipsets. This beast's theoretical 
performance is over one billion polygons 
per second. With this kind of power, we 
suddenly have the ability to create new 
real-time entertainment experiences. 

There are some other great technologies 
being developed which also support this 
convergence. Vicon has a mo-cap system 
which SCEE's Soho Studios is using to do 
motion capture of four actors simultaneous- 
ly. It can also be used for facial capture and 
the results synched with a voice recording. 
There are video cameras available that 
record color and distance from the camera; 
they are great for chromakey-style effects 
using real actors and rendered 3D environ- 
ments. With wrap-around camera systems 
like those used in The M atrix (designed by 
M anex Visual Effects), it's possible to visu- 
ally motion-capture a 3D sequence and con- 
vert it to real-time 3D for view-independent 
playback. It's truly an exciting time in the 
movie and game industries! 

Welcome 

This month marks a changing of the 
guard in our art column. Last month 
you experienced M ark Peasley's fabulous 
article on multi-legged animated critters. 
This month M aarten Kraaijvanger passes 
the art column over to M ark, who brings a 
wealth of experience with him from over 
ten years in the game industry. H e has 
worked on such games as Red Baron, Aces 
of the Pacific, and (my personal favorite) 
Stellar 7. M ark is currently the art director 
at Gas Powered Games. Find out more 
about M ark for yourself at his web site, 
www.pixelman.com. Welcome, M ark! 



Let us know what you think. Send 
e-mail to editors@gdmag.com, or write 
to Game Developer, 600 Harrison St., 
San Francisco, CA 94107 
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Patent Holders 
Respond to Editorial 

In Alex Dunne's September editorial 
("Patents, Patterns, and Other Patter," 
Game Plan), he cited my patent as one 
that G ame D eveloper readers should be 
aware of. While there's a respectable anti- 
patent position, usually it's heard from 
advocates of free software, not commer- 
cial game developers, who already license 
everything from characters to the right to 
run on a platform. We're willing to con- 
sider licensing our patents for free for 100 
percent G PL'd free software projects. 
Commercial developers must license on 
commercial terms. 

As for our physics technology being 
innovative, we're the first ones to make 
the hard cases work. We've been throw- 
ing high-poly jointed characters down cir- 
cular staircases for years now and making 
it look right; others are still banging 
boxes around. 

And as Jeff Lander and Chris H ecker's 
review showed (Product Review, Sep- 
tember 2000) major packages are having 
trouble doing even that. N or is this 
vaporware; we sell a plug-in for Soft- 
image 3D and give away a free version, 
something M athEngine announced at 
Siggraph in 1999 but never shipped. It's 
easy to do bad physics; it's much harder 
to get it right. 

We're in negotiations with various 
developers, but are not releasing details 
until the deals close. We expect this to be 
a significant technology for years to come, 
as platforms get faster and good physics 
becomes a standard part of games. 

John Nagle 
Ani mats 
via e-mail 

I just read your "Patents, Patterns, and 
Other Patter" editorial concerning GE 
M arching Cube software that appeared in 
the September 2000 issue of G ame D evel- 
oper. We appreciate your recognition of 
General Electric's work in this technology, 
and would like to take this opportunity to 
further clarify this matter. 

You should know that GE has made 
other significant contributions in visuali- 
zation technology as a result of its re- 



search in med- 
ical diagnostic 
imaging and 
aerospace. The 
GEM arching 
Cubes algo- 
rithm described 
in U.S. Patent 
4,710,876 is 
just one exam- 
ple. Some other 
examples of 
GE's contribu- 
tion to this 
technological 
area are cap- 
tured in U.S. 
Patents 
4,719,585; 
4,729,098; 
4,751,643; 
4,791,567; 
4,821,213; 4,879,668; 4,914,589; 
4,984,157; 4,985,834; 5,166,876; 
5,561,749; 5,542,036; and 5,590,248. 
They are also described in the book The 
Visualization Toolkit: An O bject-0 ri- 
ented Approach to 3-D Graphics 
(Prentice H all, 1987), and in the article 
"M arching Cubes: A H igh Resolution 3D 
Surface Construction Algorithm" (ACM 
Computer Graphics, 1987), written by 
the inventors of this technology. 

You should also know we have been 
granting licenses under these and other 
patents for various applications on fair 
and reasonable terms. 

Thank you for taking the time to issue 
this clarification. We believe these addi- 
tional comments will also be informative. 

Jerald E. Roehling 
GE Technology Development Inc. 

via e-mail 

Content More Worthy 
Than Form 

Creg Costikyan's article on games and 
stories ("Where Stories End and 
Games Begin," September 2000) is, as 
always, insightful, analytical, and illumi- 
nating. After much effort, I was able to 
discern only two points to disagree with. 

First, Greg holds that game and story 
are antithetical and must be traded off 



against each other; 
I hold that story 
emerges from 
game. A game is a 
story-generator — 
a single playing of 
a game constitutes 
a story. Thus, I 
don't see game 
and story as anti- 
thetical; I see them 
as different levels 
of abstraction. A 
game is one level 
of abstraction 
higher than a 
story, just as 
"addition" is one 
level of abstrac- 
tion higher than 
"three and two 
make five." 
Second, Greg's arguments on art and 
emotion strike me as unnecessarily defen- 
sive. H is overall thrust seems to be that 
games are every bit as good and worthy 
as stories or any other form of expres- 
sion. I argue that the worthiness of any 
particular expression arises less from its 
form than its content. There are lots of 
unworthy novels, puerile paintings, and 
vulgar movies. There is nothing intrinsic 
to games as a form of expression that 
requires them to be unworthy, puerile, or 
vulgar. These adjectives must be applied 
to individual games or to particular 
groups of games, not to the medium in 
general and certainly not to its potential. 

Thus, I find no contradiction in the 
claim that the content of most games is 
unworthy, puerile, or vulgar, while games 
as a form of expression could certainly be 
interpreted as noble, edifying, or worthy. 
Indeed, some of Greg's own games 
demonstrate the potential of the medium; 
would that they weren't swamped by the 
teeming masses of unworthy, puerile, and 
vulgar games. 

Chris Crawford 
via e-mail 



Let us know what you think: send us an 
e-mail to editors@gdmag.com, or write 
to Game Developer, 600 Harrison St., 
San Francisco, CA 94107 
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FRONT LINE TOOLS 

WHAT'S NEW IN THE WORLD OF GAME DEVELOPMENT daniel huebner & mark deloura 



3DMENOW DELIVERS 
LIP SERVICE 

Biovirtual is adding lip-synching to its 
3D M eN ow package. 3D M eN ow 
allows users to quickly create lifelike, ani- 
mation-ready 3D models from source pho- 
tographs by mapping the 
2D photographs onto the 
features of a generic 3D 
template. The resulting 
models can be manipu- 
lated with 3DM eN ow's 
3D morphing, subdivi- 
sion surface, and texture- 
blending tools and can 
be output as low-resolu- 
tion game models or in a 
more highly detailed ver- 
sion. Biovirtual is ex- 
tending the functionality 
of the package by using 
LIPSinc's technology to 
add accurate lip-synching 
with the input of any 
suitable.WAV file. 3D- 
M eN ow Pro is available 
for $1,999. 

3DMEN0W | Biovirtual | www.biovirtual.com 

GUITAR RHYTHMS FROM 
MUSIC LAB 



Pro Audio 9 for Windows 98 or NT is 
available from M usicLab for $99. 
Rhythm'n'Chords I MusicLab I 
www.musiclab.com 

NVIDIA'S MULTIMEDIA 
XBOX PROCESSOR 
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Two examples of 3DMeNow 
creating ready- to- animate 
3D models from photographs. 
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Rhythym'n'Chords deliv- 
ers access to 700 guitar 
rhythm patterns. 



I usicLab has 
I released its 
guitar rhythms 
plug-in for 
Cakewalk Pro 
Audio. Rhy- 
thm'n'Chords 
comes with a 
guitar rhythm 
library of more 
than 700 patterns. Pre-recorded patterns 
cover more than 60 accompaniment 
styles. Rhythm'n'Chords includes 22 gui- 
tar stroke types, such as down strums, up 
strums, muted strums, grace strums, 
slides, and plucking, with additional con- 
trol parameters for strum velocity, bal- 
ance, arpeggiation time, and polyphony. 
The plug-in includes a chord chart view 
as well as chord menu for the creation of 
chord progressions, and chord banks for 
storing chord configurations arranged by 
users. Rhythm'n'Chords for Cakewalk 



vidia has provided de- 
tails about the second 
processor it is supplying 
for M icrosoft's X box con- 
sole. Dubbed the X box 
M edia Communications 
Processor (M CPX), the 
part handles the broad- 
band connectivity, commu- 
nications, and audio capa- 
bilities of the X box. The 
M CPX includes dual DSPs, 
an audio processor, a 
Dolby Digital encoder, 
USB controller, modem 
interface, and an Ethernet 
controller to support home 
networking. Nvidia plans 
to begin selling an inte- 
grated chip late next year, 
which will feature a modified version of 
the M CPX with additional memory con- 
troller functions. 
MCPX I Nvidia I www.nvidia.com 

HYBRID RELEASES 
VISIBILITY OPTIMIZER 

Hybrid H olding has released 
SurRender Umbra, 
a visibility optimizer 
designed to identify visi- 
ble objects in dynamic 
3D environments as 
quickly as possible, 
without any scene pre- 
processing. Once Umbra 
has completed its tasks, 
the application can con- 
tinue by drawing only 
the visible objects, lead- 
ing to a savings in rendering time. The 
system works with environments of any 
topological structure and can be plugged 
into any game engine. The visibility 
queries are output-sensitive, meaning that 
SurRender Umbra's work time is depend- 
ent on the number of visible objects in the 




SurRender Umbra identifies visible objects in 
dynamic 3D environments. 

scene. Umbra is available for multiple 
platforms with end-product, royalty-free 
licenses running from $10,000 for a sin- 
gle platform license with no support, to 
$150,000 for all platforms with support. 
SurRender Umbra I Hybrid Holding Ltd. I 
www.hybrid.fi 

NEW SOUNDBLASTERS 
LAUNCHED 

Creative Technology has launched a 
new line of SoundBlaster cards, the 
Live! 5.1 series. This new series of sound 
cards supports 6-channel audio to deliver 
true Dolby Digital 5.1-channel surround 
sound via analog or digital connections. 
The Live! X-Gamer 5.1 and Live! M P3+ 
5.1 both address specific gaming and 
music needs, while the Live! Platinum 5.1 
offers consumers a high-end choice for 
digital audio creation and playback. The 
Live! Platinum 5.1 comes with the Live! 

Drive IR, 
which allows 
simultaneous 
connection of 
multiple 
audio devices 
through a 
panel mount- 
ed in a drive 
bay. The 
Live! Plat- 
inum 5.1 also 
ships with a 
wireless 
remote con- 
trol for easy navigation of audio and 
video playback utilities. 
SOUNDBLASTER LIVE! 5.1 1 Creative 
Technology | www.creative.com 




Creative Technology's 
X-Gamer 5.1 addresses spe- 
cific gaming needs. 



8 



d e c e m b e r 2000 I game developer 




INDUSTRY WATCH 

HE BUZZ ABOUT THE GAME BIZ d a ni e I h u eb n e r & Jennifer ol se n 



Game restrictions. The Federal Trade 
Commission report on entertainment 
marketing is having a clear effect on 
the gaming industry. K-M art and 
Wal-M art are joining Toys R Us in 
restricting the sale of mature-rated 
games. K-M art and Wal-M art have 
announced plans to restrict sales of 
M -rated game titles to anyone under 
the age of 17, and a number of 
regional department stores are plan- 
ning to follow suit. The stores will 
use a barcode scanner to remind 
clerks to check customer IDs. 

While an Indianapolis ordinance Duke 
governing the display and use of keep 
mature arcade games is being 
reviewed by the courts, a San Diego coun- 
cilman is proposing a similar measure in 
that city. As in Indianapolis, games featur- 
ing violent or sexually explicit themes 
would need to be clearly marked and kept 
at least ten feet away from non-offensive 
games. Penalties include fines up to 
$1,000 and revocation of game operator 
licenses. GameWorks, a chain of arcades, 
is introducing a new policy to restrict play 
of games identified as containing mature 
content. All 20 U.S. GameWorks and 
GameWorks Studio locations will only 
allow the sale of a limited-access debit 
card to patrons under the age of 16. 

International debates are raging on the 
subject as well, though violence and 
mature subject matter are not in the spot- 
light. Officials in the southern Chinese city 
of Guangzhou have announced a plan to 
shut down more than 1,500 videogame 
arcades because of concerns about their 
influence on children. Parents and teachers 
in the region believe that the game parlors 
are distracting students from their studies 
and causing them to make friends with the 
wrong crowd. The crackdown affects 
almost 80 percent of Guangzhou's 
arcades, most of which are being cited for 
breaking the age restrictions. M any in the 
region, however, are calling for a total 
ban. In M alaysia, H ome M inister 
Abdullah Ahmad Badawi has ordered that 
all arcades must close in two months. The 
primary motivation in that country centers 
on addiction and gambling as the reasons. 

Learning Company details. M attel won't see 
any immediate payment in its recent sale 




Nukem Forever. This game's probable M- rating would 
it from being sold at K- Mart and Wal- Mart stores. 

of The Learning Company, which it 
acquired for $3.5 billion in M ay 1999. 
Instead, the deal will allow M attel to 
share in profits from future sales of The 
Learning Company's licensed products, 
and grants M attel a chance to end the 
estimated $60-90 million quarterly losses 
associated with The Learning Company. 
The buyer, Gores Technology Group, 
hasn't disclosed any immediate plans for 
The Learning Company, but has hinted 
that layoffs are likely on the way for 
some of the company's 1,500 employees. 

Aureal buyout approved. C reative Tech- 
nology has announced that its purchase 
of beleaguered audio hardware maker 
Aureal Semiconductor has been approved. 
The U.S. Bankruptcy Court for the 
N orthern District of California, Oakland 
Division, entered the final order approving 
the sale of substantially all A ureal 's assets 
to Creative, including patents, trademarks, 
and other intellectual property. The sale 
also includes settlement of all outstanding 
litigation claims between the two compa- 
nies. Creative will pay $28 million in cash, 
plus two new shares of Creative stock for 
every 100 outstanding shares of Aureal 
stock, which amounts to 208,079 shares of 
Creative, valued at approximately $4.35 
million based on the fair market value at 
the time of the sale. 

Infogrames merger complete. Infogrames 
has finished consolidating its N orth 
American operations. The complex deal, 
involving nearly 50 million shares of 
Infogrames Inc. stock and the retirement 



of $128.6 million of debt, effectively 
combines the operations of the for- 
mer GT Interactive with those of the 
Infogrames SA's N orth American 
subsidiary. The newly merged com- 
pany will finally shed its outdated 
GTIS N asdaq symbol in favor of 
IFGM . Infogrames also made 
changes in the management of its 
newly unified North American oper- 
ations, adding Paradigm Enter- 
tainment's Dave Gatchel as senior 
vice president of development, and 
Cathy Tische from 3DO as vice pres- 
ident of licensing. 



ATI posts loss. ATI Technologies has 
reported its second straight quarterly loss. 
The company saw revenues for the fourth 
quarter drop to $290.2 million for a net 
loss of $45.2 million. ATI posted earnings 
of $16.8 million on revenues of $304.7 
million in the same quarter last year. 
After a difficult summer that included 
both the resignation of the company's 
chief financial officer and a third-quarter 
loss that triggered a stock slump, ATI is 
predicting 30 percent growth, quarter 
over quarter, for the first part of its 2001 
fiscal year. # 




UPCOMING EVENTS N 



MACWORLD EXPO 

Moscone Convention Center 
San Francisco, Calif. 
J anuary 9-12, 2001 
Cost: $25 and up (early- bird dis- 
counts available) 
www.macworldexpo.com 

IDEA 2001 & GAME 
TECHNOLOGY 
CONFERENCE 

Hong Kong Convention and 
Exhibition Centre 
Hong Kong 

Conference: J anuary 17-21, 2001 
Expo: J anuary 18-21, 2001 
Cost: (exhibits only) HK$20 per day 

(conference) HK$3,700 
www.idea-expo.com 
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PATTERNS 

/J/^(5AME PROGRAMMING PATTERNS & IDIOMS edited by chris hecker & zachary booth Simpson 

^ j www. gamasutra.com/patterns 

State Decision and 
Consequence Separation 

a.k.a. Duplicated State Decision Points 

submitted by dave weinstein 



Introduction 

Not only is this our first pattern to be 
selected from our readership, it is 
also our first "anti-pattern." N ot long 
after the release of the infamous D esign 
Patterns book, another popular book, 
A nti Patterns, followed which enumerated 
patterns of software failure. N ot surpris- 
ingly, it is often more valuable to know a 
problem than to know a solution. 

Problem 

Games frequently consist of large num- 
bers of interrelated state transitions. 
The complexity of such state machines is 
difficult to manage, and this is especially 
true for multiplayer games where the likeli- 
hood of clients receiving messages inappro- 
priate for their state must be addressed. 

A common method of implementing 
such state transitions, usually because of 
lack of time or laziness, is to separate the 
decision-making process from the resulting 
consequences. For example, when a packet 
arrives, a flag is set in one module while 
several remote modules monitor that flag 
to modify their behavior. 

This anti-pattern captures the complex- 
ity that results as such related code frag- 
ments increase. The greater the separa- 
tion, both in terms of location in the 
source code and in logical association 
between decisions and consequences, and 
the more such code is part of ad hoc 
development rather than coherent design, 
the worse the anti-pattern gets. 

Common problems include: difficult to 
follow code flow; state errors introduced 
as old functions are used as boilerplate 
for new code; the flow of state transitions 
is spread across the entire codebase lead- 
ing to difficulty in changing or introduc- 
ing new states; and code changes are 
increasingly vulnerable to human error 
because the distributed nature of the anti- 
pattern makes individual changes appear 
reasonable. 



Examples 

ne common form of the anti-pattern is 
created by repeated state checks at the be- 
ginning of functions, aborting the function 
if the state is inappropriate. For example: 
onMenuSelectO { 

if ( ! inMenuMode ) return; 

} 

This construct is initially a straightfor- 
ward way to monitor state and may work 
well for small codebases containing a lim- 
ited number of states. H owever, it 
becomes increasingly vulnerable to failure 
as numerous ad hoc decision points accu- 
mulate. This is especially true when other 
programmers integrate code and blindly 
copy poorly understood code fragments, 
propagating state decision points into 
places with unexpected and difficult to 
test results. 

Solutions 

Solutions involve minimizing disjoint 
decision and consequence processing. 
A common implementation combines the 
two operations (decision and consequence) 
into one module with related data struc- 
tures or a class responsible for the entire 
state transition sequence. This should be 
bolstered with a well-documented process 
for how state transitions are to be added 
and how state-dependent code is to be inte- 
grated into this scheme. As an example, 
consider a multiplayer game which upon 
transitioning state also filters those packets 
which are irrelevant to the state. This 
might be done with an array of valid pack- 
ets as in the following pseudocode: 

changeState( neuState ) { 
switch ( neuState ) 
case mainMenuMode: 
validPacketsPtr = 
mainMenuModeValidPackets ; 

} 

An alternative solution is to define a 
uniform interface that allows state-depend- 



ent objects to be tested in a centralized 
manner. For example: 

processMessage( Msg *msg ) { 

if ( msg->isValid() ) msg->process(); 

} 

// ChangeEquipmentMsg 
// inherits and extends Msg 
ChangeEquipmentMsg: :isValid() { 
return state == inventoryMode; 

} 

In this example, the is-message-valid rules 
are encoded into the message class. n the 
surface this seems to suffer the problems of 
the anti-pattern by distributing state deci- 
sions and consequences, but the code can be 
considered easier to follow because of the 
single point where message processing is 
aborted depending on the state checks. 

Issues 

It is crucial to document how to add and 
change states, and how to query them in 
your game to avoid ad hoc solutions like 
this anti-pattern describes. However, inter- 
nal documentation is always the first thing 
to give when a schedule begins to slip, so 
this is a hard issue to overcome. 

Related Patterns and 
References 

Solutions to this pattern are related to 
the State and Strategy patterns. See 
AntiPatterns: Refactoring Software, 
Architectures, and Projects in Crisis by 
William Brown and others (Wiley & 
Sons, 1998). 

Credits 

Thanks to Dave Weinstein from Red 
Storm Entertainment for submitting 
this anti-pattern! Be sure to follow up with 
Dave on www.gamasutra.com/patterns. # 



Send your patterns and idioms to us at 
patterns@d6.com. 



www.gdmag.com 
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PRODUCT REVIEW 



SKINNY ON NEW TOOLS 

Never Learn 
Another Editor! 

MicroEdge's Visual SlickEdit 5.0 

by mark deloura 



Tl here are so many programming 
editors out there: VI, Emacs, 
Notepad, Edit, Brief, Jed, Zeus, 
Epsilon, KEdit, CodeWright, 
FTE, GWD, M ulti-Edit, Visual 
C++'s editor, and many others. With so 
many options available, what features dif- 
ferentiate them from each other? 

If you're a Windows programmer, 
you've probably learned to get along with 
the M icrosoft Visual C++(VC) editor, so 
any replacement editor will have to get 
along with VC very well. n game con- 
sole or handheld projects, you may not 
have an IDE or editor provided, instead 
you get to roll your own environment. 
For cross-platform projects, having one 
editor that works the same for each oper- 
ating system and development environ- 
ment would be fabulous. If you're a Unix 
hacker but you have to work under 
Windows, wouldn't it be great to have 
something with a bit more functionality 
than VI, perhaps something that has func- 
tion prototype tooltips? 

In this article I'll examine Visual Slick- 
Edit 5.0 (henceforth known as Slick), a 
multi-platform editor which incorporates a 
great many programmer-friendly features. 
Because Slick has so many features, I'm 
going to concentrate on those parts which 
are particularly useful or innovative to you 
as a programmer. 

Visual C++ Integration 

Let's start at the top. Paramount for 
any editor is interoperability with VC, 
because VC is the dominant development 
environment for Windows. M ost of you 
are familiar with the VC IDE and editor. 
H ow well does Slick cooperate? 

In an ideal world you could use Slick in 
the VC editor pane. There are packages 
that do this, but I have yet to see any that 



work properly. Slick runs as a separate 
application, and it has many hooks to 
facilitate cooperation with VC. 

M ost important is Slick's ability 
to dissect workspace (.DSW) and 
project (.DSP) files. As you can see 
in Figure 1, the Files tab on the left 
pane of Slick looks very similar to VC's. 
Unfortunately, Slick doesn't let you change 
or save workspace and project files for 
VC. This is perhaps the most annoying 
thing in Slick, so it's all uphill from here. 
But this means any time you want to add 
a file to your project you have to go back 
to VC and do it from there. Fortunately, 
Slick will detect the modification and 
auto-load the updated files. Projects which 
aren't VC (such asGCC projects) can be 
easily modified in Slick. 

Building, debugging compiler errors, 
and executing your application all can be 
done from within Slick. Slick calls the VC 
command line utilities for each of these 
operations, and you stay within the editor. 
You can also configure the menu options 
to execute your own compilers and tools 
for custom projects. The regular expres- 
sions used for parsing the compiler errors 
can even be changed. 

Slick doesn't do program debugging, 
profiling, or resource editing, so you'll still 
have to rely on VC or other packages for 
that functionality. Slick does integrate well 
with a variety of source code control sys- 
tems, including SourceSafe, RCS, and 
PVCS. 

Flexibility 

The absolute best feature of Slick is its 
amazing flexibility. Everything is con- 
figurable. The primary configuration 
change you'll make is what editor should 
be emulated: CUA (standard Windows 
interface), Slick text edition, Brief, Epsilon, 




VI, Emacs, 
VC, or ISPF (an OS/390 editor). I tested 
most of these and discovered them to be 
very useable emulations. Being a die-hard 
Unix hacker, I was most interested in the 
VI and Emacs modes. VI emulation worked 
very well and even emulated some of the 
more esoteric regular expression features. 
Emacs emulation was similarly well done, 
except many of the extended functions nor- 
mally provided through Emacs Lisp were 
missing. 

Extensive configurability is built into the 
core of Slick. H otkeys are bound to macros 
(functions), and the macros can also be 
called up from the editor's command line. 
The macros are written in Slick-C, an inter- 
preted C-like language. It's easy to modify 
existing macros or create new ones, bind 
them to hotkeys, and tie them to particular 
file types. You can also modify all of Slick's 
forms and dialog boxes. Slick includes a 
complete form editor, and you can edit any 
available form, or create new ones. 

I'm completely stunned by the configu- 
ration capabilities of Slick. It's possible to 
tune the entire editor for any development 
kit, allowing you to use the editor as a 
"home base" to compile and execute from. 
This is truly an editor designed by pro- 
grammers, for programmers. 

Language Support 

So how easily will Slick let you work 
with your code? Well, remember that 
this is an editor, not an IDE, though some- 
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FIGURE 1. You can load Visual C++ workspace files into Visual 
SlickEdit. This is the Windows version, demonstrating the use of 
the References tab. 



times that's easy to forget with so much 
functionality. You won't get to step 
through your code, peer at variables, or 
dump the register set. Slick does do a lot 
of things that you'd expect from an IDE 
though, and you'll be pleasantly surprised 
by many of the additional features that are 
included in this editor. 

When you start Slick for the first time, 
it will prompt you for the location of your 
C/C++ header files and Java Development 
Kit in order to create tag files. Slick sup- 
ports many languages, but particularly 
well supported are C/C++, Java/Javascript, 
HTM L, and Slick-C. Of course, if your 
favorite language isn't supported, it's rela- 
tively simple to add your own macros to 
support syntax coloring and the like. 

After Slick creates the tag files, you're 
ready to program. All my examples from 
hereon will be regarding C++ support. 
Let's say you're working on a console title 
and need to link with the operating system 
libraries provided to you. The next thing 
you'll want to do is add all the OS code 
that you have available to the C tag file — 
from then on you'll get tooltips for all of 
your OS functions. 

As you enter code, Slick parses it 
dynamically so that it can keep track of 
function prototypes, comment blocks, 
classes, and symbol references. If you cre- 
ate comment blocks above your func- 
tions, Slick automatically includes those 
comments in the function tooltips. You 
can also use J avadoc-style comments to 
include information for your functions. 
Using Javadoc you can add HTM L -for- 
matted comments to each function. This 
is amazingly useful: you can comment 
each parameter required for a function 



call and include clickable 
links (for additional infor- 
mation), which pop up in 
the function tooltip. 

As you enter code, the 
lower pane of the Slick inter- 
face seems to psychically in- 
terface with you in order to 
display useful information. If 
you have the Symbol tab se- 
lected, the lower pane will 
dynamically display informa- 
tion that Slick thinks you 
need to know. For example, 
type a class variable and the 
file containing its class declaration will 
automatically open to help you select the 
proper member or function. If you have 
the References tab selected instead and hit 
Control-/, the lower pane will display all 
references to the symbol your cursor is on. 

Features I Now Can't 
Live Without 

Avery useful and simple concept in 
Slick is "Selective Display." Selective 
Display modifies what you can see in the 
edit pane based on preprocessor defini- 
tions or function boundaries. I use this 
feature to collapse every function down 
to a simple "plus" box (like a Windows 
Explorer folder) with the function decla- 
ration. This does wonders for improving 
the readability of code. Just click the plus 
by the declaration to pop a function 
open, then edit it and click the plus again 
to close the function up. 

Slick also performs code beautification. 
Set up your preferred tab spacing and 
curly bracket positions, then click "beauti- 
fy" to apply those settings to all your 
existing code. All code that you type or 
paste in after beautification will also auto- 
matically adjust to your beautification set- 
tings and current tab level. This is espe- 
cially useful when you have a team of peo- 
ple working on the same code. 

M oving code between Windows and 
Unix is a breeze. Slick determines which 
OS the code came from based on line- 
ending character sequences, and then dis- 
plays it without the nasty control 
sequences or merging the entire file into 
one long line. When saved, the code is 
then written out in its native format 
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regardless of the S you're running on. 

Some of the other very useful features 
in Slick include: an integrated FTP client 
which allows you to load-edit-save with- 
out ever saving to your local disk; a very 
full-featured differencing/merging utility 
(DIFFzilla); and a built-in hex editor. 

Ballistics Report 

The team at M icroEdge clearly under- 
stands what developers find useful in 
an editor. You can download a 30-day 
demo version of Slick from M icroEdge's 
web site. 

I can't recommend it enough for its func- 
tionality as an editor. Using it under Linux, 
or with custom console compilers and link- 
ers, is a dream. But when programming 
under Windows, working simultaneously 
with VC and Slick rapidly begins feeling 
like a chore. It would be nice to have just 
one tool, and even though theVC editor is 
inferior, it's often easier to just open VC for 
a quick edit and compile. # 



VISUAL SLICKEDIT 5.0 



STATS 

MicroEdge Inc. 
Apex, N.C 
(919) 303-7400 
www.slickedit.com 

PRICE 

$295 for Windows or Linux versions; $395 
for other Unix versions. 

) SYSTEM REQUIREMENTS 

Windows: 486DX or higher, 16MB RAM, 
28MB hard disk 

Linux: 486DX or higher, 24MB RAM, 40MB 
hard disk 

) PROS 

1. Extensive configurability. 

2. Huge feature set with innovative tooltip 
useage. 

3. Great for Linux and console build envi- 
ronments. 







CONS 

1. Troublesome to use with Visual C++. 

2. Hard to find what you're looking for in 
the GUI. 

3. On the pricey side. 
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3D Objects That Don't Deflate 
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FIGURE 1. The crusher. 

Like many kids who grew up in 
the suburbs, I spent the hours 
after school looking for some- 
thing to keep me from having 
to confront my homework. 
The rule was, "Be home when the street- 
lights come on." I would get home from 
school, chow down a quick mini-pizza (you 
gotta eat), then head out to basketball court 
to shoot hoops with the gang. This time of 
year was a bit of a drag. Growing up on the 
West Coast, I never needed to worry much 
about the cold in December, but the days 
were definitely getting shorter. We would 
just barely get a couple of games in before 
we had to pretend we could actually still see 
the basket. The streetlights would flicker on 
but that was easy enough to deny. It gener- 
ally took a loud whistle from someone's 
parent to break up the game. 

I usually brought my own ball. If every- 
one brought a ball, we would never have a 
situation where we didn't have one. nee 
everyone was there, the inspection began. 
Various qualities of faux leather were dis- 
cussed. Overly worn or glassy-smooth balls 
were immediately discarded. The merits of 
over- and underinflating were then debated. 
We were all avid bike riders, so we had our 
pumps ready to correct any inflation issues. 




FIGURE 2. The crushed. 

Usually the problem was that no one could 
find one of those magic inflation needles. 
We could never find one of them when we 
needed it, even though I think I personally 
had bought dozens of them. M any nights 
we had to play with a "clunker" because 
no one had one of those damn needles. To 
this day I still treat those things with an 
odd kind of reverence. When I find one in 
the back of a drawer, I attempt to put it 
somewhere where I will immediately be 
able to find it when I need it. This in- 
evitably means that I immediately lose it 
again. I am sure there are dozens of those 
things lying around here somewhere. 

Why am I thinking about this? Well, 
some of my 3D models are looking a bit 
deflated lately, and I could really use one 
of those needles to pump them up. 

Where's Dig- Dug When 
You Need Him? 

The image in Figure 1 is the cartoon taxi 
I created for this column in June ("In 
This Corner, the Crusher!"). In that col- 
umn, I described the use of a dynamic 
mass-and-spring system connected to a 
matrix deformation lattice. This allowed 
me to make a polygonal mesh squash and 



stretch like a cartoon object. The technique 
worked well, but there was a bit of a draw- 
back to the system that I tried to pass off 
as a feature. The mesh system would occa- 
sionally collapse in on itself and stay that 
way, as you can see in Figure 2. For a car, 
that may be acceptable, but for many 
objects it would not work. 

To solve the problem, I need to under- 
stand the reason this happens in the first 
place. M y dynamics model is composed of 
a grid of point masses connected by 
springs. The springs initially attempt to 
keep each point the same distance away 
from each other. Let me take a cube as an 
example. The cube is composed of four 
point masses in each direction, making a 
total of 64 mass positions. Each of these is 
connected by a spring to each of its neigh- 
bors along the axes, as you can see in 
Figure 3. This gives me 27 smaller cube 
elements that make up the larger object. 

When it's just resting there, these springs 
are enough for the object to hold its shape. 
I call these structural springs. Unfortu- 
nately, those springs alone are not enough. 
I need to add springs across the diagonals 
to keep each small cube element from 
shearing or stretching too much. Those 
springs are enough to keep each small cube 
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FIGURE 3. The spring cube. 



element from col- 
lapsing on itself. 
H owever, there is 
still a pretty big 
problem. Because the 
system is just a series 
of point masses con- 
nected by springs, it 
doesn't really repre- 
sent a solid (but 
compressible) vol- 
ume. Each element 
can pass through 
another one or occu- 
py the same space 
with no penalty. As 
long as the connect- 
ing springs are at their rest length, all is 
well as far as the simulation is concerned. 
The image, however, looks plenty wrong, 
as you can see in Figure 4. The original 
cube is no longer discernable, even though 
the simulator has reached equilibrium. 

Throw Me a Volume 
Preserver 

Clearly, I need to make the simulator 
aware that each element contains a 
volume of material that would like to 
return to its rest position. Initially the 
impulse is simply to start adding more 
springs all over the place; connect every 
other mass node, then every third mass 
node, and so on. It should be obvious that 
this could rapidly degenerate into a situa- 
tion where every mass node was connected 
to every other node by a spring. Extra 
spring calculations are a hit on perform- 
ance, so it seemed that I should attack the 
problem from a different angle. 

In mechanical engineering applications, 
the finite element method is often used for 
problems of deformation analysis. However, 
the method is fairly computationally expen- 
sive and difficult to implement for arbitrary 
models. For right now at least, I am not 
ready to give up on the mass-and-spring 
method. The goal for my deformable model 
is that is should deform naturally but tend 
to return to its initial shape when forces are 
not applied to counteract that tendency. The 
distance relationship between the mass 
nodes is initially given at load time. I really 
want those mass nodes not only to maintain 
equal distance between each other, but also 




FIGURE 4. The collapsed cube. 



to maintain their locations relative to the 
initial local origin of the object. The prob- 
lem with this is that because the object is 
free to move and tumble about in 3D space, 
I cannot simply pull the nodes back to the 
initial starting place. I need to create a local 
origin for the deformable object. For a rigid 
3D body, this is easy. The object has both a 
center of mass (COM) and an orientation 
about that center. H owever, my soft-body 
object doesn't have a rigid CO M or orienta- 
tion, as that is constantly changing as the 
object deforms. I need to find a way to 
determine the center and orientation for the 
deformable object. 

Journey to the Center 
of the Object 

Once I determine the center of mass 
and orientation of a deformable body, 
it will be useful for a variety of things. 
Collision detection comes to mind right 
away. Determining whether two rigid bod- 
ies have collided is difficult. However, colli- 
sion detection between two deformable 
bodies can become even more complicated. 
The bounding box of the object is not stat- 
ic. This provides me with a clue for how to 
determine the orientation of the object. 

An oriented bounding box (0 BB) is a 
box that surrounds an object in an orienta- 
tion that provides a nice, tight fit around 
the object. I could use the orientation and 
center of an BB for my local object axis. 
For an arbitrary set of 3D points, an OBB 
can be created by first finding the center of 
the box. The center of the box is deter- 
mined by averaging the points in the 



object. This average point is now consid- 
ered the center of mass. That was the easy 
part; now it gets a bit trickier. 

To determine the axes of the bounding 
box, I need to create a covariance matrix 
of the points in the model. The unit- 
length eigenvectors of this matrix are the 
axes of the OBB. If you are confused by 
terms like eigenvectors, you should pick 
up a linear algebra book. I never thought 
I would use it back when I was attending 
college, but more and more I find myself 
looking to linear algebra for all sorts of 
game applications. I've also found Dave 
Eberly'snew book, 3D Game Engine 
D esign (see " For M ore I nformation" ), 
very useful for calculating the BB. H is 
samples are very easy to adapt to situa- 
tions like this. I'm not going to go into 
the BB stuff this month because there 
was another problem once I had it work- 
ing. (Isn't that always the way? h well, 
now I have the OBB generation code 
ready to go when I need it.) 

The problem with the BB code is while 
it returns a box that contains the object, 
the bounding box can be created in an 
arbitrary orientation as long as it contains 
the points of the object in a fairly efficient 
way. There is not necessarily any corre- 
spondence between the initial object orien- 
tation and the orientation of this bounding 
box. This is not a problem with the BB 
algorithm. It works exactly as advertised; 
however, it caused me to refine my defini- 
tion of what information I actually needed 
to solve the problem. I need an orientation 
with a correspondence to the initial 
object's fixed reference. 
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FIGURE 5 (top). Center vector found. 
FIGURE 6 (bottom). The rotation axis in action. 

Second Attempt at a 
Tumbling Axis 

The next step was simply to consider 
the outer hull of the object and deter- 
mine the principal axes from the orienta- 
tion of the hull nodes. Let me first look at 
the left and right sides of the cube. I can 
calculate the average of the nodes on each 
side and create a vector between those 
two averaged points. This vector corre- 
sponds to the X -axis vector of the object's 
local coordinate frame. You can see this in 
Figure 5. 

I can then do the same for the top and 
bottom nodes. This will give me the Y-axis 
vector for the object. To get the Z -axis, I 
can then just cross the X - and Y-axes 
using the cross product operator, giving 
me a Z-axis perpendicular to the two 



other axes. Because the X - and 
Y-axes might not be perpendicu- 
lar to each other in a deformable 
model, I need to do another cross 
product to make sure I have a 
valid rotational matrix. This 
matrix is representative of the 
deformed object in an arbitrary 
orientation. The code to calculate 
the transformation matrix for the 
deformable object can be found 
on the G ame D eveloper web site. 
The center of mass position is 
stored in the translation portion 
of the matrix so the vertices can 
be easily transformed between 
coordinate frames. You can see 
the rotation axis in action in 
Figure 6. 

Pump you Up 

ow that I have a local trans- 
formation matrix for my 
deformable object, I can try to re- 
inflate my crushed cube. The ini- 
tial mass node positions are 
transformed through the object 
matrix. This tells me where the 
nodes should be in the current 
orientation. I then use a spring 
for each node to pull the object 
back to its original shape. The 
strength of these springs is the 
strength with which the object 
regains its original shape. The 
springs should be strong enough 
to keep the object from collapsing on 
itself, and can be used to simulate different 
types of materials which have different 
snap back properties. 

Other Simulation 
Changes 

While I was noodling in the dynamics 
simulation code, I changed a few 
things around from what I had been using. 
I changed the collision response system to 
use the penalty method instead of backing 
up the simulator to find the exact time of 
collision. When a collision is detected, a 
strong impulse is applied to the point of 
collision to force the objects apart. This 
system allows some penetration of the 
objects into the boundaries, but this is 
minimal. It also means that I don't need to 



back up the simulator and search for the 
time of collision. I will discuss this system 
more next month. 

I also changed the numerical integrator. 
If you remember my article on integration 
techniques ("Lone Game Developer Battles 
Physics Simulator," Graphic Content, April 
1999), I had implemented several numeri- 
cal integrators. I read about a variation on 
one in Jack Crenshaw's M ath Toolkit for 
Real-Time Programming (see " For M ore 
Information") that I thought was interest- 
ing. If you recall from that column, the 
dynamics simulator uses an integrator to 
integrate the acceleration on a body for a 
timestep, h, to determine the velocity, and 
integrates the velocity for the timestep to 
determine the new position of the object. 
In that article, I treated both integration 
steps as separate operations. H owever, 
Crenshaw's book points out that dynamics 
simulations such as this use a second-order 
differential equation: 



d 2 x 
dt 2 



f t,x, 



f(t,x,v) 



We reduce this to two first-order equations 
by introducing the variable, v, for velocity: 

dx 

dT v 

dv 
dt 

Crenshaw uses a predictor- cor rector for- 
mula where the velocity is calculated using 
the previous acceleration and this gener- 
ates the next step's velocity, which is used 
in the acceleration integration: 

x i+ i = x, +-(v l+1 +v,) 

This integration technique seems to per- 
form solidly and is very fast to calculate. 
G rab the source code and executable demo 
off the G ame D eveloper web site at 
www.gdmag.com. # 
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Unmasking Photoshop's 
Layers 




hotoshop has been around for 
a long time, and has reigned 
supreme for most of that time. 
There is a good reason for that. 
In a word, it's "depth." Photo- 
shop is one of those programs that seems to 
have more and more features and functionali- 
ty the deeper you dig into it. Like peeling an 
onion, it reveals new and amazing things with 
each new layer that is exposed. 

In this month's column, I'll explore some of 
the more advanced uses of layers and how a 
game artist might be able to take advantage of 
them in the everyday production environment. 
Some of the most powerful aspects of Photo- 
shop are often not utilized by artists simply 
because they've not been exposed to where 
they might be useful in their everyday work. 
Let's take a familiar-sounding scenario and 
bring some advanced layering to bear on it in order to expose 
some of the flexibility. 

Our story unfolds as our hero, Joe the artist, sits down in front 
of his computer for his morning coffee and e-mail routine. In 
rushes the designer/producer/art director (you choose) and says, 
" Sorry to dump this on you, J oe, but we need a logo for our new 
game idea, Gum bo's Revenge. I was thinking of a metallic, sort of 
old-world look and, you know, don't spend too much time on it, 
but make it look cool." 
"Oh, and we need it by noon." (Insert big, heartfelt grin here.) 
After a momentary bout of panic, Joe pops on his headphones 
and starts to build the ultimate layered Photoshop file (see ex- 
ample, above right). H is goal is 
to create a document that is 
flexible, and can be altered eas- 
ily without too much trouble. 
By using layer masks and clip- 
ping groups, he can create a file 
that is nondestructive. This 
means that it can be changed 
with little effort while main- 
taining its original look. 
H ere's how he did it: 
First, an appropriate photo 
source for both the wood and 
the metal layer needs to be found 




(see Figures 1 and 2). There is a ton of source material available 
from texture CDs, personal collections, or the web, but make sure 
that you know the copyrights associated with whatever file you 
choose. Another alternative is to use a program such as Bryce 4 or 
Corel Texture and make your own metal using some of the proce- 
dural textures applied to simple primitives. If you have access to a 
digital camera, a short walk around the building can glean a sur- 
prising number of high-quality textures. 

We'll start out by creating a new file in Photoshop called 
GUM BO and then do a copy/paste of our source textures into the 
new file as layers. We will also add our logo elements on separate 
layers to make building our masterpiece easier. 





i r 1 




















FIGURE 1 (above left) & FIGURE 2 (above right). Wood and metal photo sources used as a starting point. 
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Open up the wood source file and copy its contents into 
the clipboard. Paste this into a layer in your new GUM BO 
file and label it "Wood Base." It's a good idea to start out 
with labeling each new layer, as it will save time later. 
N ext, copy the metal texture you have and paste it into 
the document as a new layer. Label it "Steel Base." 

N ow we'll add our speedily done logo to the mix (see 
Figure 3). In a vector program of choice, create a black 
and white version of the logo or graphic to be used. In 
this case, it was created in Coreldraw and exported as 
an Adobe Illustrator file. Over the years, I've found that 
it's generally easier to do all of my more advanced typo- 
graphical manipulations in a vector-based program. They 
offer a much higher degree of control than can be found in 
the base Photoshop application. I highly recommend that game 
artists familiarize themselves with one of the main vector pro- 
grams (such as Adobe Illustrator, M acromedia Freehand, or 
Coreldraw) and add them to your creative arsenal. A firm grasp 
of the basics and the ability to control the vector aspects of 
these programs can lead to untold hours of time saved in the 
raster arena. 

I usually break any main graphic or logo elements out into indi- 
vidual files so that they can be imported into Photoshop on differ- 
ent layers. This is especially important if the various elements stack 
on top of one another in the design. In the case of our Gum bo 
logo, the elements don't overlap, so we can bring it in as one layer. 

The files from the vector program need to be saved as either 
.Al (Adobe Illustrator) or .EPS (Encapsulated Postscript) files. 
nee in this format, they can be added as a new layer in Photo- 
shop by using the Place command. The layer name is generated 
automatically based upon the vector file name. The advantage of 
using vector files and the Place function is that they are only ras- 
terized when you have finally sized them to your desired width 
and height. This gives you the cleanest version of the rasterized 
logo, and it comes in with a transparent background. The color 
of the vector files is relatively unimportant, as we will be using 
these layers for selection sets for the most part. 

N ow that the base layers are in the file, we can begin to do 
some specialized work on the individual layers. First, let's look at 
our wood. It came in O.K., but we want to add some tooth or 
depth to the grain to make it pop a bit more. 

In the Layers palette, Alt-click on the eyeball of the layer labeled 
Wood Base. This hides the other layers and makes only the Wood 
Base layer visible. Duplicate the wood layer (drag the layer down to 
the Create New Layer icon on the bottom of the palette window), 
and label the duplicate "Wood Grain." In order to see what is hap- 
pening in the next step more easily, Alt-click on the eyeball of 
Wood Grain. This will make it the only visible layer (see Figure 4). 

N ow, double-click on the layer itself right over the label. This 
brings up the Layers ptions window, which we need for the next 
step. Leave the default settings as they are and select the twin 
black pyramids below the grayscale bar labeled This Layer. Slide 
them to the right and notice what happens to your image. It begins 
to clip the black areas out of the image, leaving them transparent. 
Slide it to the right until about half of the dark area is transparent. 
Select the twin white pyramids to the right and begin to slide them 
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FIGURE 3 (above). 
The black and white 
version of the logo. 
FIGURE 4 (right). 
The wood layer is 
duplicated and re- 
named Wood Grain. 
FIGURE 5 (lower 
right). The layer is 
split and blended in 
the Layer Option 
panel. 

towards the left. 
Eventually, you 
will see clipping 
of the white areas 
of the wood. 
M ove the twin 
white pyramids 
to the left until 
you have dropped 
out about half of 
the remaining 

white area. The clipping effect threshold for each range can be 
softened by pressing the Alt key while sliding the pyramids left or 
right. This splits each one into two parts and will give you a "soft" 
selection. Slightly soften each range (see Figure 5). 

Now lock this transparency into your Wood Grain layer. Even 
though you see the effect on the screen, if you look at the layer's 
thumbnail, you will notice that it isn't displaying any transparen- 
cy. Add a new layer between the Wood Base and Wood Grain lay- 
ers, select the Wood Grain layer, and collapse it down to the 
empty layer (the shortcut for this is Control-E). 

You should now see the new layer has the transparency we 
wanted locked down. A quick check of the layer icon will verify 
that it has the alpha applied. Unfortunately, when we collapsed 
it down the layer lost its name, so rename the new layer "Wood 
Grain" again. 

Now for some fun — turn on the eyeball of both the Wood 
Grain and Wood Base layers. This makes the effect easier to see. 
Right-click on the Wood Grain layer and select Effects. Turn off 
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the Apply toggle on the Drop Shadow effect. In the pull-down 
menu, select Bevel and Emboss. Toggle the Apply on and start 
playing around with the various settings on the different pull- 
down menus. You will see some fairly dramatic effects that can be 
achieved easily (see Figure 6). 

Another thing you can do is to add a layer mask to the Wood 
Grain layer. To do this, make sure the layer is selected, and then 
click on the lower-left icon on the Layers palette. This will add an 
alpha channel that is linked to the RGB layer, and flood-fill the 
alpha channel with white. The net result of this is no apparent 
change to the RGB image. However, what has happened is that an 
active, linked alpha channel has been created for that specific layer. 
To see what that means, select black as your foreground color, and 
select the paint tool of your choice. By painting with black on the 
layer mask, you are making that part of the image transparent. 
Conversely, by painting back in with white, the RGB portion of 
the image is brought back. The advantage of using a layer mask as 
opposed to just using an eraser on the RGB layer is that it is non- 
destructive. You can always go back into the layer mask and paint 
white back into the image, and it will become visible again. 

Metal Effect 

I ow that you have the wood layer looking like you want, it's 
I time to start working on the metal part of the logo. n our 
Gumbo logo, I've decided I wanted a base metal plate that the 
entire thing sits on, so I'll take the Steel Base layer and duplicate 
it. Rename the duplicate layer "Plate" and add a layer mask. 
H old the Alt key down and click on the eyeball to make it the 
only visible active layer. N ow, with the Control key depressed, 
click on the logo layer that was a result of the imported vector 
graphic. In the case of this file, it's called GUM BO .Al. When you 
do this you should see the hand cursor change to one with a 
small marquee added to it as you roll over the logo layer. This 
loads the transparency values of the layer as a selection set into 
the layer you are currently on. 

Because we want to make this a plate that extends beyond our 
letters, we need to grow or expand the selection set. Go to the 



Select>M odify>Expand menu available from the main menu bar. 
In the case of this logo, I chose 15 as the number of pixels to 
expand the current selection. N ow, invert the selection by pressing 
Control-Alt-I. The last step is to fill black into the Plate layer 
mask with the selection we have. The result is a plate that sur- 
rounds where our logo will be (see Figure 7). 

We can now add some layer effects to increase the visual 
interest of the plate. Right-click on the Plate layer in the Layers 
palette and select Effects. Bear in mind that the numbers are 
pixel-based. So if you are working on a high-resolution image, 
you will need to crank the numbers up quite a bit beyond what 
is being done on this 640x480 image. Also, click on the eyeball 
of both the Wood Base and Wood Grain layers. It makes it easi- 
er to see the results of the next step. 

Leave the Drop Shadow toggle on, and set the distance to 5, 
the blur to 30, and the intensity to 100. N ow, go to the main 
effect pull-down and select Bevel and Emboss. With this effect 
toggled on, set the style to Inner Bevel. Also set the depth to 
around 10 pixels and the blur to 5 pixels. Leave all other set- 
tings at their default values. 

You should now see a plate of metal lying over the wood base. 
Depending upon the lettering style or logo, there may end up 
being some unwanted holes in your steel plate. This is easy to fix 
by going directly into the layer mask and painting with white to 
remove the holes. An easy way to see just the active layer mask is 
to Alt-click directly on the Plate layer mask thumbnail in the 
Layers palette. This will turn all other layers off and display only 
the layer mask. Alt-clicking again on the same thumbnail returns 
you back to where you started. 

Adding the Logo 

I ow that we have the Plate layer in reasonable shape, let's 
I add the logo and play around with how that's going to 
look. An easy way to get started is simply to drag the Plate layer 
down to the Create N ew Layer icon at the bottom of the Layers 
palette. This will create a duplicate layer with all effects and 
masks intact. Rename the copy " Letters" and fill its active layer 





FIGURE 6. A Drop Shadow and a Bevel and Emboss effect are added to the layer. FIGURE 7. The Plate layer is duplicated and renamed "Letters 
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mask with black. This will give you a layer that is 
visually empty, but has all of the settings we creat- 
ed for the Plate layer just waiting to be used. M ake 
sure that the only visible layers are Letters, Plate, 
Wood Grain, and Wood Base. 

N ow load up the logo as a selection set. Do this by 
Control-clicking on the logo layer. M ake sure that 
you have the Letters layer mask selected by clicking 
on the black thumbnail. It's sometimes easy to have 
the RGB channel selected instead of the layer mask. 
Visually, your only clue as to which one is active is a 
small black outline around the thumbnail itself. So, 
with the Letters layer mask selected, fill the selection 
set with white. You should immediately see a raised- 
letter version of the logo become visible. I readjusted 
the drop-shadow effect to a distance setting of and 
a blur setting of 15 for better visual appeal. 




FIGURE 8. The Adjustment layer is merged with the Bones layer for the final image. 



Adding Another Plate Level 

After a quick critique of the logo, I decided that an additional 
metal plate was needed between the word "Revenge" and 
the plate we just made. Once again, simply select and drag the 
Letters layer down to the Create N ew Layer icon and rename it 
" Plate 2." Select the layer mask for Plate 2 and fill it with black. 
The newly created layer also needs to be placed in the correct 
order in the layers stack. To do this, select and drag the Plate 2 
layer between the Plate and Letters layers. 

N ow we need to create a layer that will be used as a selection 
set for our new Plate 2 layer. I could always just load my logo 
layer up and do some fancy selecting and de-selecting, but if a 
mistake is made the penalty is starting over. An easier method is 
to build temporary layers that are used only for selection sets. 
These layers can be left invisible when not in use. 

With that in mind, create a new layer and call it "Plate Selec- 
tion." In this layer, create a shape for the second plate and fill it 
with black. With the visibility of the Plate Selection layer turned 
off, make the Plate 2 layer active. Control-click on the Plate 
Selection layer to load it up as a selection set. M ake sure the Plate 
2 layer mask is selected (click on the thumbnail) and fill the selec- 
tion with white. J ust like that, we have another plate in the image 
that is fully editable. 

Finishing Touches 

As the noon hour draws near, J oe the artist puts on some finish- 
ing touches to give the image some pop. Once again, a non- 
destructive approach gives him the most flexibility with the file. 

After some quick evaluation, Joe decides that the word 
"Gumbo" needs some color. He can take advantage of layer 
masking in another powerful way: clipping groups. 

First, add a new layer above the Letters layer and call it 
"Gradient." M ake Gradient the active layer and fill it with a trans- 
parent ramp to red. Accomplish this by selecting the linear gradient 
tool, making red the foreground color, and setting the Options tab 
from Foreground to Transparent under the Gradient pull-down. 



Once this is done, select Overlay from the layer blending 
mode pull-down at the top of the Layers palette. We now want 
to have this red gradient effect only visible in the word 
"Gumbo." This can be accomplished easily by making the 
Gradient layer a clipping group of the Letters layer. Alt-click on 
the line between the Gradient layer and the Letters layer. When 
you have the Alt key depressed, the cursor will turn into two 
overlapping circles with an arrow when it rolls over the line. 
The successfully clipped layer can be identified by a dotted line 
between the two layers. 

The next-to-last step is to make the fish bones look better. 
Duplicate the layer that contains the fish bones, which in our 
case was the Letters layer. Rename it "Bones," and drag it to the 
top of the layers stack. Alt-click on the Bones layer mask to 
make it more clearly visible. Select everything except for the fish 
shape, and fill it in with black. Alt-click again to return the logo 
to the normal view. 

Finally, add an Adjustment layer. Go to the main tool bar and 
select Layers>N ew>Adjustment Layer. Select H ue/Saturation 
from the available choices, and set the Saturation to -100 and 
the Lightness to +75. M ake this a clipping group for the Bones 
layer by Alt-clicking on the line between the H ue/Saturation 
layer and the Bones layer (see Figure 8). 

With only minutes to spare, our hero Joe has once again 
pulled through in a clinch and delivered a file that is not only 
flexible but easy to manipulate. This type of approach to build- 
ing nondestructive graphics works extremely well when design- 
ing graphical user interfaces or any other elements in Photoshop 
that are prone to continual evolution and tweaking. The down- 
side is that the file size becomes fairly large, but with today's 
systems, that is usually not an issue. By playing around with 
some of these advanced layers techniques, you'll find yourself 
with an amazing amount of control, and be able to increase 
your production speeds substantially. # 
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ngel Studios' M idtown M adness 2 for 
PC and M idnight Club for Playstation 
2 are open racing games in which 
players have complete freedom to 
drive where they please. Set in "liv- 
ing cities," these games feature 
interactive entities that include 
opponents, cops, traffic, and pedestrians. The role of artifi- 
cial intelligence is to make the behaviors of these high-level 
entities convincing and immersive: opponents must be com- 
petitive but not insurmountable. Cops who spot you break- 
ing the law must diligently try to slow you down or stop 
you. Vehicles composing ambient traffic must follow all 
traffic laws while responding to collisions and other unpre- 
dictable circumstances. And pedestrians must go about their 
routine business, until you swerve towards them and pro- 
voke them to run for their lives. This article provides a stra- 
tegy for programmers who are trying to create A I for open 
city racing games, which is based on the success of Angel 
Studios' implementation of AI in M idtown Madness 2 and 
M idnight Club. The following discussion focuses on the 
autonomous architecture used by each high-level entity in 
these games. As gameplay progresses, this autonomy allows 
each entity to decide for itself how it's going to react to its 
immediate circumstances. This approach has the benefit of 



creating lifelike behaviors along with some that were never 
intended, but add to gameplay in surprising ways. 

AI Map: Roads, Intersections, 
and Open Areas 

At the highest level, a city is divided into three primary 
components for the A I map: roads, intersections, and 
open areas (see Figure 1). M ostof thisAI map is composed 
of roads (line segments) that connect intersections. For our 
purposes, an intersection is defined as a 2D area in which 
various roads join. Shortcuts are just like roads, except they 
are overlaid on top of the three main component types. 
Shortcuts are used to help the opponents navigate through 
the various open areas, which by definition have no visible 
roads or intersections. Each of these physical objects is 
reflected in a software object. 

The road object contains all the data representing a 
street, in terms of lists of 3D vertices. The main definition of 
the road includes the left/right boundary data, the road's 
centerline, and orientation vectors defined for each vertex in 
the definition. Other important road data includes the traf- 
fic lane definitions, the pedestrian sidewalk definition, road 
segment lengths, and lane width data. A minimum of four 
3D vertices are used to define a road, and each list of ver- 



joe adzima Joe has been an A I programmer at Angel Studios for three years. D uring that time, he architected and 
implemented the entire AI system for M idtown Madness 1 and 2 for PC and M idnight Club for Playstation 2. Joe thanks 
Robert Bacon, Angel Studios' technical writer, for the exceptional editorial efforts Robert has applied to this article. 
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tices (for example, center vertices, boundary vertices, and so on) 
has the same number of vertices. 

The intersection object contains a pointer to each connected 
shortcut and road segment. At initialization, these pointers are sort- 
ed in clockwise order. The sorting is necessary for helping the ambi- 
ent traffic decide which is the correct road to turn onto when tra- 
versing an intersection. The intersection object also contains a 
pointer to a "traffic light set" object, which, as you might guess, is 
responsible for controlling the light's sequence between green and 
red. Other important tasks for this object include obstacle manage- 
ment and stop-sign control. 

Big-city solutions: leveraging the City Tool and GenBAI Tool. Angel's 
method for creating extremely large cities uses a very sophisticated 
in-housetool called the City Tool. N ot only does this tool create 
the physical representation of the city, but it also produces the raw 
data necessary for the A I to work. The City Tool allows the regen- 
eration of the city database on a daily basis. H ence, the city can be 
customized very quickly to accommodate new gameplay elements 
that are discovered in prototyping, and to help resolve any issues 
that may emerge with the A I algorithms. 

The GenBAI Tool is a separate tool that processes the raw data 
generated from the C ity Tool into the format that the run-time code 
needs. Other essential tasks that this GenBAI Tool performs include 
the creation of the ambient and pedestrian population bubbles and 
the correlation of cull rooms (discrete regions of the city) to the 
components of the road map. 

Based on the available A I performance budget and the immense 
size of the cities, it's impossible to simulate an entire city at once. 
The solution is to define a "bubble" that contains a list of all the 
road components on the city map that are visible from each cull 
room in the city, for the purpose of culling the simulation of traffic 
and pedestrians beyond a certain distance. This collection of road 
components essentially becomes the bubbles for ambient traffic 
and pedestrians. 

The last function of the GenBAI tool is to create a binary version 
of the data that allows for superfast load times, because binary data 
can be directly mapped into the structures. 

Data files: setting up races. The A I for each race event in the 
game is defined using one of two files: the city-based A I map 
data file or the race-based Al map data file. The city file contains 



FIGURE 1. The Al map elements appear as green and blue 
line segments for roads and sidewalks, 2D areas for intersec- 
tions, and additional line segments for shortcuts across open 
areas. 

defaults to use for all the necessary A I settings at a city 
level. Each race event in the city includes a race-based 
Al map data file. This race file contains replacement 
values to use instead of the city values. This approach 
turns out to be a powerful design feature, because it 
allows the game designer to set defaults at a city level, 
and then easily override these values with new settings 
for each race. 

Some examples of what is defined in these files are 
the number and definition of the race's opponents, 
cops, and hook men. Also defined here are the models 
for the pedestrians and ambient vehicles to use for a specific race 
event. Finally, exceptions to the road data can be included to 
change the population fill density and speed limits. 

Curves Ahead: Creating Traffic 

Following rails and cubic spline curves. During normal driving 
conditions, all the ambient vehicles are positioned and oriented 
by a 2D spline curve. This curve defines the exact route the ambi- 
ent traffic will drive in theXZ-plane. We used H ermite curves 
because the defining parameters, the start and end positions, and 
the directional vectors are easy to calculate and readily available. 

Since the lanes for ambient vehicles on each road are defined by 
a list of vertices, a road subsegment can easily be created between 
each vertex in the list. When the ambient vehicle moves from one 
segment to the next, a new spline is calculated to define the path 
the vehicle will take. Splines are also used for creating recovery 
routes back to the main rail data. These recovery routes are neces- 
sary for recovering the path after a collision or a player-avoidance 
action sent the ambient vehicle off the rail. Using splines enables 
the ambient vehicles to drive smoothly through curves typically 
made up of many small road segments and intersections. 

Setting the road velocity: the need for speed. Each road in the A I 
map has a speed-limit parameter for determining how fast ambient 
vehicles are allowed to drive on that road. In addition, each ambi- 
ent vehicle has a random value for determining the amount it will 
drive over or under the road's speed limit. This value can be nega- 
tive or positive to allow the ambient vehicles to travel at different 
speeds relative to each other. 

When a vehicle needs to accelerate, it uses a randomly selected 
value between 5 and 8 m/s 2 . At other times, when an ambient vehi- 
cle needs to decelerate, perhaps because of a stop sign or red light, 
then the vehicle calculates a deceleration value based on attaining 
the desired speed in 1 second. The deceleration is calculated by 



2(X-X ) 

where V is the target velocity, V is the current velocity, and (X - 
X ) is the distance required to perform the deceleration. 
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Detecting collisions. With performance times being so critical, 
each ambient vehicle can't test all the other ambient vehicles in its 
obstacle grid cell. As a compromise between speed and comprehen- 
siveness, each ambient vehicle contains only a pointer to the next 
ambient vehicle directly in front of it in the same lane. On each 
frame, the ambient checks if the distance between itself and the next 
ambient vehicle is too close. If it is, the ambient in back will slow 
down to the speed of the ambient in front. Later, when the ambient 
in front becomes far enough away, the one in back will try to 
resume a different speed based on the current road's speed limit. 

By itself, this simplification creates a problem with multi-car pile 
ups. The problem can be solved by stopping the ambient vehicles at 
the intersections preceding the crash scene. 

Crossing the intersection. nee an ambient vehicle reaches the end 
of a road, it must traverse an intersection. To do this, each vehicle 
needs to successfully gain approval from the following four func- 
tional groups. 

First, the ambient vehicle must get approval from the intersection 
governing that road's "traffic control." Each road entering an inter- 
section contains information that describes the traffic control for 
that road. Applicable control types are NoStop, AllwaysStop, 
TrafficLight, and StopSign (see Figure 2). If NoStop is set, then the 
ambient vehicle gets immediate approval to proceed through the 
intersection. If AllwaysStop is set, the ambient never gets approval to 
enter the intersection. If TrafficLight is set, the ambient is given 
approval whenever its direction has a green light. If StopSign is set, 
the ambient vehicle that has been waiting the longest time is ap- 
proved to traverse the intersection. 

The second approval group is the accident manager. The accident 
manager keeps track of all the ambient vehicles in the intersection 
and the next upcoming road segment. If there are any accidents 
present in these Al map components, then approval to traverse the 
intersection is denied. Otherwise, the ambient vehicle is approved 
and moves on to the third stage. 

The third stage requires that the road which the ambient is going 
to be on after traversing the intersection has the road capacity to 
accept the ambient vehicle's entire length, with no part of the vehi- 
cle sticking into the intersection. 

The fourth and final approval comes from a check to see if 
there are any other ambient vehicles trying to cross at the same 
time. An example of why this check is necessary is when an ambi- 
ent vehicle is turning from a road controlled by a stop sign onto a 
main road controlled by a traffic light. Since the approval of the 
stop sign is based on the wait time at the intersection, the vehicle 
that's been waiting longest would have permission to cross the 
intersection — but in reality that vehicle needs to wait until the 
cars that have been given permission by the traffic light get out of 
the way. 

Selecting the next road. When an ambient vehicle reaches the end 
of the intersection, the next decision the vehicle must make is which 
direction to take. Depending on its current lane assignment, the 
ambient vehicle selects the next road based on the following rules 
(see Figure 2): 

• If a vehicle is in the far-left lane, it can go either left or straight. 

• If it's in the far-right lane, it can go either right or straight. 

• If it's in any of the center lanes, then it must go straight. 




FIGURE 2. In this case, the TrafficLight class is set to red for some vehi- 
cles, which stop and wait. The other vehicles with green/yellow lights get 
permission to cross the intersection. The vehicle crossing in the left lane 
decides to turn left, while the vehicle in the right lane goes straight 



• If it's on a oneway road, then it picks randomly from any of 
the outgoing roads. 

• If it's on a freeway intersection where on-ramps merge with 
the main freeway traffic, then it must always go right. 

• U-turns are never allowed, mostly because a splined curve in 
this situation would not look natural. 

Since the roads are sorted in clockwise order, this simplifies 
selection of the correct road. For example, to select the road to the 
left, just add 1 to the current road's intersection index value (the 
ID number of that road in the intersection road array). To pick the 
straight road, add 2. To go right, just subtract 1 from the road's 
intersection index value. 

Changing lanes. n roads that are long enough, the ambient ve 
hides will change lanes in order to load an equal number of vehi- 
cles into each lane of the road. When the vehicle has traveled to 
the point that triggers the lane change (usually set at 25 percent of 
the total road length), the vehicle will calculate a spline that will 
take it smoothly from its current lane to the destination lane. 

The difficulty here is in setting the next-vehicle pointer for colli- 
sion detection. The solution is to have a next-vehicle pointer for 
each possible lane of the road. During this state, the vehicle is as- 
signed to two separate lanes and therefore is actually able to detect 
collision for both traffic lanes. 

nee a vehicle completes the lane change, it makes another deci- 
sion as to which road it wants to turn onto after traversing the up- 
coming intersection. This decision is necessary because the vehicle is 
in a new lane and may not be able to get to the previously selected 
road from its new lane assignment. 

Orienting the car. As the ambient traffic vehicles drive around the 
city, they are constantly driving over an arbitrary set of polygons 
forming the roads and intersections. One of the challenges for the 
A I is orienting the ambient vehicles to match the contour of the 
road and surfaces of open areas. Because there are hills, banked 
road surfaces, curbs separating roads and sidewalks, and uneven 
open terrain, the obvious way to orient the vehicles is to shoot a 
probe straight down the Y-axis from the front- 1 eft, front-right, and 
rear-left corners of the vehicle. First, get the XZ position of the 
vehicle from the calculated spline position and determine the three 
corner positions in respect to the center point of the vehicle. Then, 
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shoot probes at the three corners to get their Y positions. 

Once you know the three corner positions, you can calculate 
the car's orientation vectors. This approach works very well, but 
even caching the last polygon isn't fast enough to do all the time 
for every car in the traffic bubble. ne way to enhance perform- 
ance is to mark every road as being either flat or not. If an ambi- 
ent vehicle drives on a flat road, it doesn't need to do the full 
probe method. Instead, this vehicle could use just the Y value 
from the road's rail data. Another performance enhancement is 
to orient the vehicles that are far enough from the player using 
only the road's rail-orientation vectors. This approach works well 
when small vehicle-orientation pops are not noticeable. 

Managing the collision state. When an ambient vehicle collides 
with the player, or with a dynamic or static obstacle in the city, the 
ambient vehicle switches from using a partially simulated physics 
model to a fully simulated physics model. The fully simulated mo- 
del allows the ambient vehicle to act correctly in collisions. 

A vehicle manager controls the activities of all the vehicles transi- 
tioning between physics models. A collision manager handles the 
collision itself. For example, once a vehicle has come to rest, the ve- 
hicle manager resets it back to the partially simulated physics mo- 
del. At this point, the ambient vehicle attempts to plot a spline back 
to the road rail. As it proceeds along the rail, the vehicle will not 
perform any obstacle detection, and will collide with anything in its 
way. A collision then sends the vehicle back to the collision manag- 
er. This loop will repeat for a definable number of tries. If the maxi- 
mum number of tries is reached, the ambient vehicle gives up and 
remains in its current location until the population manager places 
it back into the active bubble of the ambient vehicle pool. 

Using an obstacle-avoidance grid. Every A I entity in the game 
is assigned to a cell in the obstacle-avoidance grid. This assign- 
ment allows fully simulated physics vehicles to perform faster 
obstacle avoidance. 

Since the road is defined by a list of vertices, these vertices make 
natural separation points between obstacle-avoidance buckets. To- 
gether, these buckets divide the city into a grid that limits the scope 
of collision detection. As an ambient vehicle moves along its rail, 
crossing a boundary between buckets causes the vehicle to be re- 
moved from the previous bucket and added to the new bucket. The 
intersection is also considered an obstacle bucket. 

Simulation bubbles for ambient traffic. A run-time parameter spec- 
ifies the total number of ambient vehicles to create in the city. After 
being created, each ambient vehicle is placed into an ambient pool 
from which the ambients around the player are populated. This 
fully simulated region around the player is the simulation bubble. 
Relative to the locations of the player, remote regions of the city are 
outside of the simulation bubble, and are not fully simulated. 

When a player moves from one cull room to another, the popula- 
tion manager compares the vertex list of the new cull room against 
the list for the old one. From these two lists, three new lists are cre- 
ated: New Roads, Obsolete Roads, and No Change Roads. First, 
the obsolete roads are removed from the active road list, and the 
ambient vehicles on them are placed into the ambient pool. N ext, 
the new roads are populated with a vehicle density equal to the to- 
tal vehicle length divided by the total road length. The vehicle den- 
sity value is set to the default value based on the road type, or an 



exception value set through the definition of the race Al map file. 

As the ambient vehicles randomly drive around the city, they 
sometimes come to the edge of the simulation bubble. When this 
happens, the ambient vehicles have two choices. First, if the road 
type is two-way (that is, ambient vehicles can drive in both direc- 
tions), then the vehicle is repositioned at the beginning of the cur- 
rent road's opposite direction. Alternatively, if the ambient vehicle 
reaches the end of a one-way road, the vehicle is removed from the 
road and placed into the pool and thereby becomes available to 
populate other bubbles. 

Driving in London: left becomes right. London drivers use the left 
side of the road instead of the right. To accommodate this situation, 
some changes have to be made to the raw road data. First, all of the 
right lane data must be copied to the left lane data, and vice versa. 
The order of each lane's vertex data must then be reversed so that 
the first vertex becomes the last, and the lane order reversed so that 
what was the lane closest to the road's centerline becomes the lane 
farthest from the center. 

Given these changes, the rest of the A I entities and the ambient 
vehicle logic will work the same regardless of which side of the 
road the traffic drives on. This architecture gave us the flexibility to 
allow left- or right-side driving in any city. 

City People: Simulating Pedestrians 

In real cities, pedestrians are on nearly every street corner. They 
walk and go about their business, so it should be no different in 
the cities we create in our games. The pedestrians wander along the 
sidewalks and sometimes cross streets. They avoid static obstacles 
such as mailboxes, streetlights, and parking meters, and also 
dynamic obstacles such as other pedestrians and the vehicles con- 
trolled by the players. And no, players can't run over the pedestri- 
ans, or get points for trying! Even so, interacting with these "peds" 
makes the player's experience as a city driver much more realistic 
and immersive. 

Simulation bubbles for pedestrians. J ust as the ambient traffic has 
a simulation bubble, so do the pedestrians. And while the pedestri- 
an bubble has a much smaller radius, both types are handled simi- 
larly. During initialization, the pedestrians are created and inserted 
into the pedestrian pool. When the player is inserted into the city, 
the pedestrians are populated around him. During population, one 
pedestrian is added to each road in the bubble, round-robin style, 
until all the pedestrians in the pool are exhausted. 

Pedestrians are initialized with a random road distance and side 
distance based on an offset to the center of the sidewalk. They are 
also assigned a direction in which to travel and a side of the street 
on which to start. As the pedestrians get to the edge of the popula- 
tion bubble, they simply turn around and walk back in the opposite 
direction from which they came. 

Wandering the city. When walking the streets, the pedestrians 
use splines to smooth out the angles created by the road subseg- 
ments. All the spline calculations are done in 2D to increase the 
performance of the pedestrians. The Y value for the splines is cal- 
culated by probing the polygon the pedestrian is walking on in 
order to give the appearance that the pedestrian is actually walk- 
ing on the terrain underneath its feet. 
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FIGURE 3 (above). In this situation, the PreCrossStreet state has moved the 
pedestrians next to the street curb, and now the WaitToCrossStreet state is 
holding the peds in place until the light turns green. FIGURE 4 (top right). 
When the oncoming player vehicle threatens these pedestrians, they decide 
to hug the wall after sending out a probe and finding a wall nearby. FIGURE 
5 (bottom right). The pink lines visualize the direction the peds intend to 
walk. When a player vehicle introduces a threat, the pedestrians decide to 
dive right or left at the last moment, since no wall is nearby. 

Each pedestrian has a target point for it to head toward. This 
target point is calculated by solving for the location on the spline 
path three meters ahead of the pedestrian. In walking, the ped will 
turn toward the target point a little bit each frame, while moving 
forward and sideways at a rate based on the parameters that con- 
trol the animation speed. As the pedestrian walks down the road, 
the ped object calculates a new spline every time it passes a side- 
walk vertex. 

Crossing the street. When a pedestrian gets to the end of the 

street, it has a decision to make. The ped either follows the side- 
walk to the next street or crosses the street. If the ped decides to 
cross the street, then it must decide which street to cross: the 
current or the next. Four states control ped navigation on the 
Streets: Wander, PreCrossStreet, WaitToCrossStreet, and CrossStreet 
(see Figure 3). The first of these, Wander, is described in the previ- 
ous section, "Wandering the City." PreCrossStreet takes the pedes- 
trian from the end of the street to a position closer to the street 
curb, WaitToCrossStreet tells the pedestrian waiting for the traffic 
light that it's time to cross the street, and CrossStreet handles the 
actual walking or running of the pedestrian to the curb on the 
other side of the street. 

Animating actions. The core animation system for the pedestrians 
is skeleton-based. Specifically, animations are created in 3D Studio 
M ax at 30FPS, and then downloaded using Angel's proprietary ex- 
porter. The animation system accounts for the nonconstant nature 
of the frame rate. 

For each type of pedestrian model, a data file identifies the anima- 
tion sequences. Since all the translation information is removed from 
the animations, the data file also specifies the amount of translation 
necessary in the forward and sideways directions. To move the 
pedestrian, the ped object simply adds the total distance multiplied 
by the frame time for both the forward and sideways directions. 
(M ost animation sequences have zero side-to-side movement.) 

Two functions of the animation system are particularly useful. 
The Start function immediately starts the animation sequence spec- 
ified as a parameter to the function, and the Schedule function 




starts the desired animation sequence as soon as the current 
sequence finishes. 

Avoiding the speeding player. The main rule for the pedestrians is 
to always avoid being hit. We accomplish this in two ways. First, if 
the pedestrian is near a wall, then the ped runs to the wall, puts its 
back against it, and stands flush up against it until the threatening 
vehicle moves away (see Figure 4). Alternatively, if no wall is nearby, 
the ped turns to face the oncoming vehicle, waits until the vehicle is 
close enough, and then dives to the left or right at the very last 
moment (see Figure 5). 

The pedestrian object determines that an oncoming vehicle is a 
threat by taking the forward directional vector of the vehicle and 
performing a dot product with the vector defined by the ped's posi- 
tion minus the vehicle's position. This calculation measures the side 
distance. If the side distance is less than half the width of the vehicle, 
then a collision is imminent. 

The next calculation is the time it will take the approaching vehi- 
cle to collide with the pedestrian. In this context, two distance 
zones are defined: a far and a near. In the far zone, the pedestrian 
turns to face the vehicle and then goes into an "anticipate" behav- 
ior, which results in a choice between shaking with fear and run- 
ning away. The near zone activates the "avoid" behavior, which 
causes the pedestrian to look for a wall to hug. To locate a wall, 
the pedestrian object shoots a probe perpendicular to the sidewalk 
for ten meters from its current location. If a wall is found, the 
pedestrian runs to it. Otherwise, the ped dives in the opposite direc- 
tion of the vehicle's rotational momentum. (Sometimes the vehicle 
is going so fast, a superhuman boost in dive speed is needed to 
avoid a collision.) 
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FIGURE 6. The route 
is defined by the roads con- 
necting intersections lto 5, in order. 
Vehicle A is on road 2-3, which is the "hint 
road." Vehicle B has accidentally been knocked onto 
road 6-2. The immediate target is intersection 3 for 
both vehicles. Thus, Vehicle A's cache consists of 
roads 2-3, 3-4, and 4-5. Vehicle B's cache consists 
of roads 6-2, 2-3, and 3-4. 



Avoiding obstacles. As the pedestrians walk blissfully down the 
street, they come to obstacles in the road. The obstacles fall into one 
of three categories: other wandering pedestrians; props such as trash 
cans, mailboxes, and streetlights; or the player's vehicle parked on 
the sidewalk. 

In order to avoid other pedestrians, each ped checks all the pedes- 
trians inside its obstacle grid cell. To detect a collision among this 
group, the ped performs a couple of calculations. First, it determines 
the side distance from the centerline of the sidewalk to itself and the 
other pedestrian. The ped's radius is then added to and subtracted 
from this distance. A collision is imminent if there is any overlap 
between the two pedestrians. 

In order to help them avoid each other, one of the pedestrians can 
stop while the other one passes. Oneway to do this is to make the 
pedestrian with the lowest identification number stop, and the latter 
ped sets its target point far enough to left or right to miss the former 
ped. The ped will always choose left if it's within the sidewalk 
boundary; otherwise it will go to the right. If the right target point is 
also past the edge of the sidewalk, then the pedestrian will turn 
around and continue on its way. Similar calculations to pedestrian 
detection and avoidance are performed to detect and avoid the 
props and the player's vehicle. 

Simulating Vehicles with Full Physics 

The full physics simulation object, VehiciePhysics, is a base class 
with the logic for navigating the city. The different entities in 
the city are derived from this base class, including the RouteRacer 
object (some of the opponents) and the PoiiceOfficer object (cops). 
These child classes supply the additional logic necessary for per- 
forming higher-level behaviors. We use the term "full-physics 
vehicles" because the car being controlled for this category be- 
haves within the laws of physics. These cars have code for simu- 
lating the engine, transmission, and wheels, and are controlled by 
setting values for steering, brake, and throttle. Additionally, the 
VehiciePhysics class contains two key public methods, RegisterRoute 
and DriveRoute. 

Registering a route. The first thing that the navigation algorithm 
needs is a route. The route can either be created dynamically in 
real time or defined in a file as a list of intersection IDs. The real- 
time method always returns the shortest route. The file method is 
created by the Race Editor, another proprietary in-housetool that 
allows the game designer to look down on the city in 2D and 
select the intersections that make up the route. The game designer 
can thereby create very specific routes for opponents. Also, the file 
method eliminates the need for some of the A I entities to calculate 




FIGURE 7. The purple lines on the road show the tree of possible routes 
that this opponent vehicle is considering. The orange line shows the best 
route — which is typically the one that isn't blocked, stays on the road, and 
goes as straight as possible. 

their routes in real time, which in turn saves processing time. 

Planning the route. Once a route to a final destination has been 
specified, a little bit more detailed planning is needed for han- 
dling immediate situations. We used a road cache for this pur- 
pose, which stores the most immediate three roads the vehicle is 
on or needs to drive down next (see Figure 6). 

At any given moment, the vehicle knows the next intersection 
it is trying to get to (the immediate target), so the vehicle can 
identify the road connecting this target intersection with the in- 
tersection immediately before the target. If the vehicle is already 
on this "hint road," then the cache is filled with the hint road 
and the next two roads in the route. 

If the vehicle isn't on the hint road, it has gotten knocked off 
course. In this situation, the vehicle looks at all the roads that 
connect with the intersection immediately before the target. If the 
vehicle is on one of these roads, then the cache is filled with this 
road and the next two roads the vehicle needs to take in order to 
get back on track. If the vehicle isn't on any of these roads, then 
it dynamically plots a new route to the target intersection. 

Determining multiple routes. If there are no ambient vehicles in 
the city, then there is only one route necessary to give to an op- 
ponent (the computer-controlled player, or CCP), the best route. 
In general, however, there is ambient traffic everywhere that 
must be avoided if the CCP is to remain competitive. The choice 
then becomes which path to pick to avoid the obstacles. At any 
given moment, this choice comes down to going left or right to 
avoid an upcoming obstacle. As the CCP plans ahead, it deter- 
mines two additional routes for each and every obstacle, until it 
reaches the required planning distance. This process produces a 
tree of routes to choose from (see Figure 7). 

Choosing the best route. When all the possible routes have been 
enumerated, the best route for the CCP can be determined. Some- 
times one or more of the routes will take the vehicle onto the 
sidewalk. Taking the sidewalk is a negative, so these routes are 
less attractive than those which stay on the road. Also, some 
routes will become completely blocked, with no way around the 
obstacles present, making those less attractive as well. The last 
criterion is minimizing the amount of turning required to drive a 
path. Taking all these criteria into account, the best route is usu- 
ally the one that isn't blocked, stays on the road, and goes as 
straight as possible. 
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Setting the steering. The CCP vehicle simulated with full phy- 
sics uses the same driving model that the player's vehicle uses. 
For example, both vehicles take a steering parameter between 
-1.0 and 1.0. This parameter is input from the control pad for 
the player's vehicle, but the CCP must calculate its steering 
parameter in real time to avoid obstacles and reach its final des- 
tination. Rather than planning its entire route in advance, the 
CCP simplifies the problem by calculating a series of Steering 
Target Points (STPs), one per frame in real time as gameplay pro- 
gresses. Each STP is simply the next point the CCP needs to steer 
towards to get one frame closer to its final destination. Each 
point is calculated with due consideration to navigating the road, 
navigating sharp turns, and avoiding obstacles. 

Setting the throttle. M ost of the time a CCP wants to go as 
fast as possible. There are two exceptions to this rule: traversing 
sharp turns and reaching the end of a race. Sharp turns are 
defined as those in which the angle between two road subseg- 
ments is greater than 45 degrees, and can occur anywhere along 
the road or when traversing an intersection. Since the route 
through a sharp turn is circular, it is easy to calculate the maxi- 
mum velocity through the turn by the formula 

V = A /ugR 

where V is equal to the velocity, u is the coefficient of friction for 
the road surface, g is the value of gravity, and R is the radius of 
our turn. Once the velocity is known, all that the CCP has to do 



is slow down to the correct speed before entering the turn. 

Getting stuck. Unfortunately, even the best CCP can occasion- 
ally get stuck, just like the player does. When a CCP gets stuck, 
it throws its car into reverse, realigns with the road target, and 
then goes back into drive and resumes the race. 

The Road Ahead 

In the wake of the original M idtown M adness, we wanted open 
city racing to give players much more than the ability to drive 
on any street and across any open area. In order for a city to feel 
and play in the most immersive and fun way possible, many inter- 
active entities of real cities need to be simulated convincingly. 
These entities include racing opponents, tenacious cops, ambient 
traffic, and pedestrians, all of which require powerful and adaptive 
Al to bring them to life. M idtown M adness 2 and M idnight 
Club expand on the capabilities of these entities, which in turn 
raises the bar of players' expectations even further. 

The future of open city racing is wide open — literally. Angel 
Studios and I are planning even more enhancements to the A I in 
any future games of this type that we do. Some ideas I'm planning 
to investigate in the future include enhancing the opponent naviga- 
tion skills of all Al entities, and creating Al opponents that learn 
from the players. Additionally, I'd like to create more player inter- 
action with the city pedestrians, and have more interaction 
between Al entities. Anyone wanna race? # 
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hirty-five years ago, 
when time-sharing 
operating systems appeared 
for mainframes and the print- 
ing terminal became common, people began writ- 
ing computer games. The game industry followed about five years later, 
if we count the earliest arcade machines. In the course of the last three decades, we've wandered 
down some strange paths, hit a few dead ends, and witnessed the evolution of a new entertainment 

medium, perhaps even a new art form. 

We've also slowly evolved a discipline of sorts, a 
way of thinking about games and the 
people who play them. M uch of this 

} 

accepted wisdom is accurate, tuned by many years of 
trial and error and filtered by the natural selection of the 
marketplace. For example, we now know that great 
graphics alone do not ensure a game's success — the few games which violated that principle did 
not survive or reproduce. But a few bad ideas have managed to 
hang on as well, perhaps because they're not quite lethal 
enough to kill a company that relies on them. In 
this article, I'm going to discuss four commonly 
held beliefs about games and game design that are 
erroneous. If we could get these ideas out 
of the gene pool, we'd all be better off. 
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Myth We Are Our Own 
Audience 

The idea that we accurately represent our audi- 
ence is the foundation of just about every belief 
that we developers hold about games and game play- 
ers. We think we know what our audience likes because 
we know what we like. After all, we're not just game 
developers, we play games too, and we're convinced that this pro- 
vides us with the insight to understand all players — and potential 
players— everywhere. 

H ow many design discussions have you attended where some- 
body, in criticizing an idea, started a sentence with the words 
"N obody cares about . . ."? If you've spent any time in the indus- 
try, the answer is probably in the dozens. N obody cares about 
history (so the vast majority of games are set in science-fiction or 
fantasy worlds). N obody cares about acting (so the acting in most 
games is abominable). N obody cares about the story, everyone 
clicks through it (so the plot is trivial and the text is badly writ- 
ten). Girls don't play games (so very few games of interest to girls 
are produced). The list goes on and on. The basis for these sweep- 
ing statements is seldom any concrete evidence; it's just a belief 
that as game developers, we know what players want. 

This logic is profoundly flawed. We may play games ourselves, 
but we are a peculiar class of gamers: those who also happen to be 
game developers. We don't represent those players who don't want 
to make computer games; there aren't any of them among us. We 
can't assume that our interests are the same as theirs. 

Computer gaming is unique among entertainment media for the 
number of people that it inspires to want to make it their career. 
M ost people watch TV without wanting to produce TV shows, and 
visit fairgrounds without wanting to run the carousel, yet a surpris- 
ing number of people who play computer games also want to make 
them. Why should that be? It's because the games they're playing 
are designed for the kinds of people who are interested in making 
games — that is, they're designed by developers, for developers, or 
at least potential developers. 

In my experience, market research in this industry is little more 
than a joke — and I used to work for one of the most successful 
publishers in the business. There are a few nods in that direction; 
every now and then somebody will collect up all the warranty 
cards returned by the purchasers and read what they've said, but 
any decent statistician would laugh out loud. Warranty card 
returns come from a tiny, self-selected minority of the customers. 
All they tell you is what the sort of person who returns warranty 
cards thinks — hardly a random sample. h, and we hold focus 
groups, but who do we invite to focus groups? Experienced 
gamers — specifically, the kinds of players who would enjoy 
spending an evening bending a publisher's ear. Again, not a terri- 
bly representative group. Other than that, the market research 
I've seen has been based on little more than hunches, convention- 
al wisdom, and M yth #1. 

Worse yet, there's another group of people we're ignoring entirely: 
the ones who don't play any games at all. Right now, we developers 
are all brutally clawing each other to sell more of the same kinds of 




games in the same limited shelf space 
to the same limited market of current 
game players. The real opportunity lies 
in selling to people who don't yet play 
games, but might start if they could find a 
game that they liked. These "proto-gamers" 
are the ones we should be reaching out to, 
the people we should be trying to create products for. But we don't 
know anything about them. All we know is they're not buying the 
games that we're making now — the kinds of games that we like. 

There's a certain number of kids, mostly boys, who hang around 
the game store and buy a $40 game every few weeks. They're our 
traditional market. But there is a staggeringly huge number of peo- 
ple, mostly adults, and many of them women, who would like to 
take a few minutes between tasks at work or chores at home to 
play a light, fun, simple game that costs them a few cents, tops. 
Who's selling to them? N ot most of us, that's for sure. 

When I mention this notion to developers, especially young ones, 
I usually get a disgusted look and a flat dismissal: "I won't work on 
any game that I wouldn't want to play." The more thoughtful some- 
times add, "I'm afraid I wouldn't do a very good job if I weren't 
passionate about the game." I sympathize with that notion — I, too, 
was one of those people who felt passionate about making games 
within five minutes of playing one for the first time — but ultimate- 
ly it's short-sighted. It might be good art, but it's bad business. It still 
leaves you making games for game developers, and that's an over- 
crowded field. Passion's difficult to maintain when the game you 
spent 18 months building lasts three weeks on the store shelves. 

Consider Barbie Fashion Designer. Barbie Fashion Designer 
was not constructed by ten-year-old girls. N o offense to ten-year-old 
girls, but very few of them have the wherewithal to produce com- 
mercially viable entertainment software. Barbie Fashion Designer 
was developed by adults who were fairly unlikely to play with it 
much themselves. But in spite of that, they did an excellent job and 
they made a ton of money for themselves and their company. N ot 
knowing the developers personally, I can only assume that they re- 
lied not on passion for playing the game itself, but on a different 
quality called professionalism, the desire to do a job well for its own 
sake. And it paid off in spades. 

The way to overcome M yth #1 is to do something I have seldom 
seen done in the game industry: decide who your audience is up- 
front. Don't assume that you're selling to the same jaded old crowd 
and that you know exactly what they want. Instead, define your 
audience, then admit your ignorance about them. Go find some of 
them and actually ask what games they'd like to play, and where 
and how they want to play them. Who knows, you could discover a 
huge market that has been ignored for the last thirty years. J ackpot! 

Myth **2: Realism Is Always a Primary 
Design Goal 

What is a primary design goal? H ere's how to find out. M ake 
a list of everything you want to achieve with your game. 
These goals can be creative, technical, financial, anything. If you 
want your game to change the way the player thinks or feels, they 
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could be intellectual, emotional, or 
spiritual. They even could be po- 
litical or social, if you want your 
game to change the world. 

N ow sort your list from the 
most important goals to the least. 
Then start from the top, run 
down the list, and ask yourself of 
each goal, "If we don't achieve this, will we con- 
sider the game to be a failure?" At some point, you'll stop saying 
"yes." Your attitude will change from "this goal is essential," to 
"this would be nice but isn't critical." At that point, draw a line 
across the list. 

All the goals above the line you just drew are your primary de- 
sign goals. They're the things you absolutely must achieve. The 
goals below the line are secondary, things you'd like to include 
but you don't feel you have to, and certainly not if doing so in- 
terferes with anything higher on the list. Secondary goals can be 
sacrificed for the sake of primary goals. 

If you read enough game hype — advertising, box copy, press 
releases — you could quickly form the impression that realism is 
one of the most important features of any game. Publishers' mar- 
keting and PR departments are constantly harping on the subject, 
and if you pay attention to such things you might start to believe 
it yourself. Don't. It's M yth #2. 

Realism can and should be a primary design goal in certain gen- 
res where it matters. H igh-end flight and racing simulators demand 
realism. Few other games need it, and there are some genres in 
which concentrating on it is actively detrimental. M any games are 
set in an artificial, symbolic world, and they should be. M onopoly 
has very little to do with the realities of buying real estate, and if 
you were to include those details (taxes, insurance, inspections, ter- 
mites . . .) they would harm the game. 

The primary source of this myth is pretty obvious: it's our own 
history. The audio, video, and processing capabilities of our ma- 
chines have been continuously improving ever since the first com- 
puter game was written, and as a result, games are more realistic 
now than they ever have been in the past. M ore importantly, at 
every point in our history, the games have been more realistic than 
they ever were before. We're at the top of a steadily rising curve, 
and we always have been. 

Of course these improvements look good, they sound good, and 
they serve to demonstrate technical competence and advancement. 
But they will occur automatically if your development team is ta- 
king advantage of the target hardware. Remember: primary design 
goals are those for which you are prepared to sacrifice something 
else, if necessary. If realism is a primary design goal, what are you 
willing to sacrifice for it? 

Sometimes the answer is payability. Spectrum H olobyte's F-16 
Falcon is an extremely realistic flight simulator, and when you 
play it in that mode, you find out why very few people are good 
enough to be fighter pilots. It's damned hard to play. Realism is F- 
16 Falcon's claim to fame, its raison d'etre, so it's appropriate for 
realism to be a primary design goal, even at the expense of paya- 
bility. But it's not appropriate for most other kinds of games. 

Industry veterans probably don't need to be told this. The people 



who need to hear it are newcomers 
joining the industry from elsewhere, either 
young people fresh out of college, or people 
coming in from other industries. Those 
people are in fact the secondary source of this 
myth: their college professors taught them that accurate 
modeling was important in software engineering, and if 
they came from a job in another industry, it probably was. The guy 
who was brought in to head up EA's 3DO development team was a 
Ph.D. physicist, and he insisted that John Madden Football for 
the3DO must have "realistic" physics. Unfortunately, until we 
changed his mind, this made the game unplayable. Because the ath- 
letes in a sports game are being guided by a simplistic game con- 
troller, you have to adjust the physics to compensate, but he didn't 
understand this. I was the designer of M adden at the time, and I 
taught the programmers a mantra to chant when they got in fights 
with their boss: "It doesn't have to be 'right,' it has to look good 
and play well." Eventually we won him over. 

There's a legend from the early days at Atari that was told to 
me by someone who was there at the time. The arcade classic 
Battlezone had come out, and the U.S. Army sent some people 
around to find out how Atari was making tank simulators for a 
few thousand dollars when they were paying millions for theirs. 
There was a meeting with a lot of brass hats on one side of the ta- 
ble, and a lot of long-haired, T-shirted, dope-smoking program- 
mers on the other. The Army wanted to know how they achieved 
precision on such low-end gear. The programmers shrugged. "We 
don't," they said. The officers persisted. "So if an enemy shot 
should really miss your tank, but the computations are off and it 
hits it anyway ..." "The player loses his quarter," the program- 
mers said. " Big deal. H e's not going to know, is he?" The Army 
decided to keep its own simulators. 

Like most legends, the exact details may not be right but it's the 
message that matters, and it nicely illustrates my point about M yth 
#2. For the Army, realism was a primary design goal — a matter 
of life and death, in fact — and they sacrificed a lot of money to 
achieve it. For Atari, fun and manufacturing costs defined the pri- 
mary goals, with realism a distant second. But Battlezone was a 
great game for all that. This is an entertainment industry. Don't 
get needlessly bogged down with realism. 

Myth »3: You Can Build a Hit by 
Imitating Another Hit 

This myth tends to be believed more by business people than by 
designers. Designers usually want to innovate, not imitate. Still, 
if you look at the store shelves, there's a heck of a lot of imitation 
going on. It happens because a publisher's marketing and sales peo- 
ple notice that some competitor has had a hit, and they persuade the 
management that if the developers will just produce something like 
it, they can have a hit too. They're victims of M yth #3: the belief 
that you can build a hit by imitating another hit. 

I'm sure we've all seen this myth at work. Someone will pro- 
duce a brilliant new game, it'll be a massive hit at Christmas, and 
by the next E3 there'll be four or five schlocky knockoffs in the 
pipeline made by other people. They never look as good, because 
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chances are they're being rushed 
to market to catch the coattails of 
the original, and they never sell as well, 
because the "wow" factor is already gone. 
Why do they bother? Well, you can make a 
little money that way if you've got no pride 
and no creativity of your own. But in my 
experience the companies that do this are also-rans, 
second-rate outfits that will never really shine. For one thing, if 
the management has foisted it on the developers against their will, 
they are wasting their own talents. They have got their people 
building cheap knockoffs when they could be working on some- 
thing innovative and new. N o developer with any imagination is 
going to put up with that for long. They'll leave, and then the 
company has to find someone to replace them who doesn't mind 
working on cheap knockoffs. It's not a formula for building and 
maintaining an excellent staff. 

Oddly enough, this can even happen within a single company. 
It occurs when the marketing department insists on creating a 
sequel to a game for which no sequel was intended. Sometimes a 
game is a hit because the development team has burned them- 
selves out, put everything they had into that one game. If you 
then demand that they make another just like the first, you're 
bound to get an inferior product — they don't have anything left 
to give. With the current emphasis on franchises, we're usually 
better at product planning than that. But it still happens, especial- 
ly with games that were unexpectedly successful. 

I don't mean to suggest that you shouldn't study other people's 
games. I'm a firm believer in the value of studying other people's 
games; heck, I'm a firm believer in the value of studying every- 
thing. It's all grist for the creative mill. But there's a significant 
difference between keeping an eye on the competition and ripping 
them off. The latter is seldom successful. Our objective should be 
to surpass the competition, to create "wow" moments of our 
own, rather than hoping for a free ride on the back of someone 
else's imagination. 
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to existing, stationary steam engines. 
H e didn't invent the railroad, either. It 
was a man named George Stephenson who con- 
structed the first steam locomotive — drawing on 
the work that Watt had already done, of course. 
It's not that a great idea won't ever make some- 
one a fortune. Sometimes one does, and a lot of 
people point to Tetris as the perfect example. The 
problem is that truly great ideas on the order of Tetris are 
extremely rare. For every Tetris there are tens of thousands of 
seemingly great ideas that go nowhere. A winning lottery ticket 
will make you a fortune, too, but if you're serious about making 
money, lottery tickets are not the way to do it. 

Another game that people point to as an example of a great 
idea that made a fortune is Doom . Everyone remembers that 
Doom was like nothing ever seen before, and it enabled John 
Carmack and John Romero to buy Ferraris. But Doom wasn't 
actually a great idea from out of the blue; in fact, it's an excellent 
example of how fortunes are really made in the game industry. 

The central idea of Doom — running around and shooting 
things in the first person — was not new. There was a multiplayer 
game called M azewars on the Xerox Alto word processor as far 
back as 1983, and there are probably earlier examples. The central 
display method in Doom , a technique called raycasting, was not 



Myth «4: A Great Idea Will Make You 
a Fortune 

Several times a year, I get letters from people who have great 
game ideas, but no clue how to make them a reality. They'd 
like me to teach them all about game development and marketing, 
but they're usually very cagey about what their idea is — they're 
afraid I might steal it and make a lot of money that's rightfully 
theirs. Alas, they've been seduced by M yth #4: the notion that a 
great idea will make them a fortune. It's a classic among fledgling 
game designers, so this section is for them. 

Part of the reason people believe M yth #4 has to do with the 
way we're taught about the history of innovation. We're told neat 
little sound-bite chunks of history that don't include the whole 
story, things like "James Watt invented the steam engine." This 
gives the impression that in a world of horse-drawn coaches, 
James Watt saw the lid of his teakettle jiggling and suddenly the 
railroad was born. But J ames Watt was part of a much larger 
process, and what he really invented was a technical improvement 



www.gdmag.com 



39 



(game design 



new either. The reason Doom did so well 
was not because it was great new idea, 
but because it was a brilliant execu- 
tion of a variety of existing ideas. 
Raycasting may not have been 
new, but Doom did it better than 
anyone else. The game was so simple, 
so fast and clean, that it still has its 

devotees today. I've seen it ported to all kinds of strange devices, 
even the LCD display of a digital camera. 

That's the thing to know about fortunes in the game industry. 
There's nothing wrong with great ideas, but it's a mistake to think 
that they routinely lead to fortunes. What reliably makes money 
is not brilliant ideas, but quality workmanship: top-notch, first- 
rate, class-A execution. And the only way to obtain that is by the 
sweat of your brow. 

Your chances of selling a great idea to a publisher just in idea 
form are rapidly vanishing. nee upon a time publishers might 
have bought ideas, but they don't anymore — and in any case, 
publishing companies are full of people who all have their own 
great ideas. Unless yours is of winning-lottery-ticket caliber, no- 
body's going to pay you for it. What publishers want is not 
ideas, but people who can create products, especially with the 
kind of quality that I was talking about. 

But suppose you're still convinced that yours is a lottery-jack- 
pot idea. How do you protect it? Here's a one-paragraph primer 
on intellectual property for wannabes. In America there are three 
ways to legally protect your work: copyright, trademark, and 
patent. A copyright protects a document of some kind, either 
text, a photograph, a sound recording, or some other expressive 
material. It doesn't protect the ideas in the document, only the 
document itself. You can't copyright an idea. A trademark is a 
name, slogan, or logo that you use to represent your company or 
its products. Trademarking something prevents other people in 
the same line of business from using it as well. You can't trade- 
mark an idea, though; again, it has to be something concrete. 
Finally, a patent is a means of protecting a new method for doing 
something. N o one else must ever have done it before, and it 
actually has to be a method, not something abstract like a story 
or a character. You can patent an idea, but it has to be an idea 
about doing something, not just an image or a concept. 

So if you have a game idea like "Robot Camels from N eptune 
Invade the J ustice Department," you can't copyright, trademark, 
or patent it. You can draw a robot camel and copyright your 
drawing, and you can name the camels "Dromedroids" and 
trademark the name, but other than that you can't prevent other 
people from having and developing the same idea. Anybody else 
can make a game on the same subject. If you come up with some 
method of playing your game that has never been seen in any 
other game ever invented, you might be able to patent the 
method, but you still can't patent the robot camels. Besides, 
obtaining a patent is an expensive and time-consuming process. 
The burden of proof is on you to show that your method is so 
different from anything that anyone else is doing that you 
deserve exclusive rights to the idea. With game mechanics, that's 
going to be a tough sell. 




The one other option is to treat the idea 
as a trade secret — that is, not to tell any- 
body about it, and if you do tell some- 
one about it, to ask them to sign 
what's called a nondisclosure agree- 
ment, or N DA, first. An N DA is usu- 
ally a simple, one-page contract in which 
somebody promises not to reveal your secret to 
anyone else, in exchange for getting a chance to look at it. 
N ormally, no money changes hands. This is what I use when 
people want to consult me but don't want to tell me about their 
idea. I sign a nondisclosure agreement promising not to reveal 
their secret or use it for myself. H owever, getting signed N DAs 
doesn't take you any farther down the road to that hypothetical 
pot of gold, either. 

All this may make it sound as if I think there's no point in 
innovation, and that we might as well go on making the same 
kinds of games because great ideas are worthless. N othing could 
be farther from the truth. Great ideas are wonderful, but you 
need a realistic understanding of their value. N o single idea is 
likely to be worth a fortune, so rather than clinging to it as if it 
were a diamond, we should continually generate new ones: learn, 
think, dream, create. 

A couple of weeks ago I had the opportunity to visit a compa- 
ny called Hidden Dinosaur in Sweden. Its founder, M ichael 
Stenmark, showed me his sketch book of ideas for the project 
they're working on. To say that I was amazed would be an 
understatement — overwhelmed is more like it. H e had page 
after page of places, people, creatures, objects, stuff I had never 
seen the likes of. There wasn't an elf, samurai, or space marine 
in sight. Everything was fascinating and new, and every day he 
goes out and draws more things. H e often travels for inspiration, 
and he never stops. H e doesn't assume one idea is enough. They 
pour from his pen like a rainbow N iagara. H e's got the right 
attitude about ideas: more is better. 

If you've got a great idea, use it to practice your skills. Learn 
how to develop it. If you want to be a programmer, learn to pro- 
gram it; if you want to be an artist, learn to draw it; if you want 
to be a writer, write about it — and you can copyright all the 
material you create, so at least your labor is protected. You 
won't make a fortune, but if you work on it, your passion for it 
will show. Then you can bring it out at job interviews to de- 
monstrate your talent. Don't worry about keeping it secret. In 
fact, do the exact opposite: talk about it, to anyone who will lis- 
ten. If it's really that good, they'll be impressed with your imagi- 
nation and more inclined to hire you. 

In Conclusion 

As I said, these four myths aren't lethal mutations. Believing 
them isn't necessarily going to destroy your career or your 
company. But like flaws in the genetic code, they accomplish 
nothing, they do more harm than good, and it's undesirable to 
pass them on to the next generation. By identifying and correct- 
ing them, perhaps we can effect a few repairs on our rapidly 
growing industry. # 
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Ritual Entertainment's 
Heavy Metal: F.A.K.K. 2 




- V 



publisher: Gathering of Developers 
PROJECT LENGTH: 18 months 
NUMBER OF FULL-TIME DEVELOPERS: 11- 18 
NUMBER OF CONTRACTORS: 1 

BUDGET: Approx. $2 million 
RELEASE DATE: J uly 31, 2000 
PLATFORMS: Windows 95/98/ NT 
DEVELOPMENT HARDWARE USED: 450MHz 
Pentium lis with 256MB RAM, TNT2 
Ultras, and 13GB hard drives. 
DEVELOPMENT SOFTWARE USED: Visual C++ 
6.0, Photoshop 5.0, 3D Studio Max 3.1, 
Deep Paint 3D 

notable TECHNOLOGIES: Quake 3 engine from 
id Software, RAD Game Tools' Miles 
Sound System, InstallShield 6.2, 
DemoShield 6.51, Robocopy 1.96 (from the 
Windows NT Resource Kit) 
project SIZE: 364,825 lines of code; 

11,519 files 




he decision to create a game based in the H eavy M etal universe 
started back in the hot Texas summer of 1997. Ritual Entertainment 
was in full-blown production of Sin when our concept artist's agent, 
Russell Binder, called up one day. Russell mentioned that his client, Kevin 
Eastman, was looking to make a videogame based on a new animated 
movie called H eavy M etal: F.A.K.K. 2. Kevin told us that the name of the 
movie was based on the name of the lead character in the movie and that character was 
being based on the image of his wife, J ulie Strain. The name of the movie was later 
changed to H eavy M etal 2000, but we decided to keep the F.A.K.K. 2 name, due to the 
fact that we already had two magazine covers and previews, and we didn't want to cre- 
ate product confusion. 

Ritual jumped at the chance to create a game based in the H eavy M etal universe. 
Everyone at Ritual was familiar with the original H eavy M etal movie released in 1981, 
and a lot of us grew up reading the H eavy M etal illustrated magazine. A few business 
meetings later with Kevin and Russell brought the deal to a close. 

Ritual then hired a new development team consisting of two programmers and two 
level designers. This small team worked on preproduction of F.A.K.K. 2 during produc- 
tion of Sin in 1997 and on into the beginning of 1998. 

Circumstances arose that caused the two programmers to leave Ritual, and the level 
designers were assigned to the Sin team. This caused F.A.K.K. 2 production to slow 
down during Sin's final crunch, from M arch to October 1998. After Sin shipped, part of 
the team worked on SinCTF (a free multiplayer add-on to Sin) while the rest of the 
team moved over to work on F.A.K.K. 2. When SinCTF was released to the Internet, the 
F.A.K.K. 2 team was fully realized. We started off with five programmers, five artists, 
five level designers, one support person, one sound engineer, and one project manager. 
H owever, when we finished the game the core team consisted of three programmers, 
three artists, three level designers, one sound engineer, and one support person. Art 
director Robert Atkins was the only team member that survived from the beginning of 
preproduction to the very end of the project when F.A.K.K. 2 went gold on July 31, 
2000. 

In the midst of this turnover, many of the original design team left, and many ele- 
ments of the original design laid out in preproduction had to be rewritten. F.A.K.K. 2 
production began in earnest in early M arch 1999 with the new design. 



scott alden Scott is currently working as a programmer on D uke N ukem Forever at 3D Realms. H e was one of the senior program- 
mers on F.A.K.K. 2 and Sin for Ritual Entertainment. Scott started his career in the gaming industry at 3D fx I nteractive, where he provided 
support for the Voodoo 1 graphics card. H e can be contacted at scotta@3drealms.com. 
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RIGHT, Q3Radiant level 
design tool showing the 
Shield Generator puzzle. 
BELOW. Concept sketch of 
Lord Tyler (final boss). 





What Went Right 

ITeam familiarity with the 
• engine. We originally intend- 
ed to use Ritual's UberEngine for 
F.A.K.K. 2, but it lacked some neces- 
sary components to complete the 
entire game. The U berEngine was 
basically all the components we 
designed and added to the Quake 2 
engine for the development of Sin , 
plus a new renderer and 
networking layer. There 
was still a lot of work 
to be done on the 
UberEngine, 
though, and we 
chose to license a third- 
* -r party engine for the proj- 
ect. The team was very famil- 
J iar with the Quake 2 engine 
(thanks to Sin ), and it was pret- 
ty high on our list of choices. 
The other engines we considered 
Lithtech and Unreal. We came to 
conclusion that we would have to do a 
ork to any engine (besides Q uake) 
to do some of the things that we 
designed in the preproduction of 
K. 2. 

Luckily, an early version of the 
Quake 3 engine became avail- 
able at the last moment before 
we had to make a final deci- 




sion. We ultimately ended up with a limited 
Quake 3 license where we got a snapshot 
of the code in February 1999. Q uake 3 
had not been released yet, but it was in a 
workable state when we first got the code. 
This was the best decision we made during 
the entire project. 

Ritual Entertainment is extremely fa- 
miliar with the Quake family of engines, 
having started out with the Q uake 1 engine 
on the Quake M ission Pack #1: Scourge 
of Arm agon. N ext, Sin was initially devel- 
oped under a modified Q uake 1 engine and 
was converted over to Q uake 2 late in the 
project. The team was very relieved that we 
wouldn't have to add the extra learning 
time that it would take for us to become 
familiar with Lithtech or Unreal. The level 
designers would not have to learn a new 
editor, and since they were already familiar 
with the capabilities of the Quake engine, 
they could build prototype levels very 
quickly at the beginning of the project. 

From the programmers' standpoint, it let 
us leverage all of the code that we wrote 
during our development of Sin . We were 
able to drop in the Sin game code and get a 
working version of the game very quickly, 
including our scripting language. 

We received the Q uake 3 code in late 
February 1999 and had a very impressive 
technology demo ready for E3 in early 
M ay. Since we had five programmers at 
the beginning of the project, in the early 
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months of the project we were able to drop 
tons of new features into the engine and 
show them off at E3. 

2 In-game tools and engine modi- 
• fications. The modifications that 
we made to the Q uake 3 engine helped us 
put on the finishing touches and ultimately 
garnered F.A.K.K. 2 such praises as "The 
M ost Beautiful Game Ever." After hearing 
some of those comments, all the extra work 
required really was worth it. Almost all of 
the tools that we created on top of the 
Quake 3 engine allowed the level designers 
and artists to create content with a text file. 
When a system was designed, we always 
took into account how the team was going 
to use it. We used text files and simple 
English commands to allow the designer or 
artist to make game changes without having 
to recompile anything. 

Another element that we added to the 
tool system was the ability to edit things in 
the game engine itself. This saved a lot of 
time for the artists and level designers. 
They got to see their changes immediately 
on the screen instead of having to exit out 
of the game and restart every time they 
changed something. 

Skeletal animation system and LOD. ne of 
the first modifications to the engine was the 
addition of a skeletal animation and level- 
of-detail (LOD) system. This allowed us to 
put in a ton of animations for the game's 
main character, Julie. We could also throw a 
lot of in-game models and monsters on the 
screen thanks to the LO D system. ur lead 
animator, Darrin Hart, hand-animated 
11,000 frames of animation, of which 
about 6,500 frames were actually used in 




the game. This would not have 
been possible with a vertex- 
based animation system. 

Morpheus scripting lan- 
guage. O ne of the best 
systems we came up with 
during the development of 
Sin was the scripting 
system. We gave it 
the internal nick- 
name M orpheus, 
partly in tribute to 
The M atrix, and 
partly due to the fact 
that you could do just about any- 
thing you wanted to with it. 

The scripting system is described 
in more detail in the Postmortem of 
Sin I wrote (M arch 1999), but in a 
nutshell the scripting language 
gives the level designer complete 
control over any object or entity in 
the game. The functionality it pro- 
vides ranges from the simple linear 
movement of objects around the level 
to the complex scripted sequences that 
exist throughout F.A.K.K. 2. We 




7 



extended 
the function- 
ality from Sin 's 
500 or so commands 
to about 700 in 
F.A.K.K. 2. This 
added complexity 
put a more rigor- 
ous demand on 
the level designer, 
as they really had to put 
on a programmer's cap in 
order to use the scripting 
language in F.A.K.K. 2. 
TIKI animation system. The 
DEF animation system from Sin 
was ported over in the early 

LEFT In-game model of J ulie wear- 
ing her flightsuit. 

BELOW LEFT In-game screenshotof 
the Ghost particle system menu. 
BELOW RIGHT. 3D Studio Max showing 
J ulie in the battlesuit with various 
armor attachments. 
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stages of F.A.K.K. 2 development and renamed TIKI. Its main func- 
tion was to allow the text file definition of models in the game. It 
also allows events to be synched with the animation on a per-frame 
basis. It was largely used for synching sounds and effects with the 
character animation. 

Ghost particle system. The Ghost particle system was written 
completely from scratch and incorporated into the M orpheus 
scripting language and the TIKI animation system. Ghost allows 
artists and level designers to create user-defined particle systems 
and integrate them into the game via the animation system. As is 
the case with almost every Ritual-created engine modification, 
this is accomplished with a simple text file. There are about 50 
commands used to modify the parameters of a particle system, 
and the systems can be combined together to create some com- 
plex-looking effects. For example, the firing oftheUzi in the 
game is a combination of five particle systems: smoke, shells, 
muzzle flash, tracer, and impact debris. 

Cinematic camera system. F.A.K.K. 2 is a very cinematic-inten- 
sive game. The story demanded some very complex scenes to ad- 
vance the story, and we wanted to show as much detail as possi- 
ble in these cinematic elements. We started with the spline-based 
camera system in Sin and ported it over to F.A.K.K. 2. We also 
added the ability to edit the camera paths in the game, actor 
tracking, and field-of-view control. This gave the cinematic de- 
signer complete control over the scene and allowed him to pre- 
view his changes immediately. 

Sound system (Zound). Another in-game system istheZound edi- 
tor. This system let our sound engineer place sound and music trig- 
gers in the game without having to recompile the entire level. This 
allowed him to place music cues and music mood triggers around 
the level to create tension or humor when needed. 

5 Third-party license and creative control. Kevin 
• Eastman is the owner of the H eavy M etal magazine and 
co-creator of the Teenage M utant N inja Turtles. Together with 
Simon Bisley, they were the creative force behind the H eavy M etal 
2000 movie. When we discussed the possibilities of the game, we 
came up with idea of the game being a sequel to the movie instead 
of doing the standard movie-to-game conversion. H e was thrilled to 
hear this, and fully supported our decision to make the game a 
sequel to the movie. 




TOP. In a scene from Heavy Metal 2000] ulie convinces Germaine St. 

Germaine to help her out. 

BOTTOM. The Ghost particle system in action. 

Very early in the production we received a crate full of H eavy 
M etal magazines — every single issue. We spent days poring over 
the issues to see what kinds of styles H eavy M etal is known for, 
and to get inspiration for designing the characters. 

Kevin also gave us complete control over the story and provid- 
ed us with some inspirational concept sketches, which influenced 
the design of the game. Working with Kevin has been a blast and 
he's supported us completely with our decisions on what to put in 
the game. For instance, when we decided to resurrect Lord Tyler 
from the movie, Kevin wholeheartedly agreed. 

4 Focus on single-player. Early in the development of 
• F.A.K.K. 2, we decided to focus solely on the single-play- 
er aspect of the game. This was a very tough decision for the 
team, as just about everyone at Ritual loves to play multiplayer 
games, and Quake 3 deathmatch is a frequent pastime around 
the office. 

Since the team was small, we decided to focus on the single- 
player aspects of the game instead of trying to do multiplayer, 
which usually has an impact on what can be accomplished in the 
single-player version. We came up with a very tight game design 
and avoided repetitive gameplay. Almost every level in the game 
presents the player with new monsters and weapons. 
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All of the levels were sketched on paper before the level design 
ers started working. They used these 2D maps to get a feel for 
how the level was going to be laid out and where all the action 
and encounters were going to take place. Another part of pre- 
production that helped out was the detailed description of the 
game's characters and monsters. The character sheets gave the 
artists the knowledge of how the creature was going to function 
in the game, which helped them create the necessary animations. 



5 Strong focus on graphics. Right from the beginning of 
• the project, we decided to focus strongly on graphics. We 
wanted the visual experience in the game to be something unpar- 
alleled in the game industry. Since the game is in third-person 
perspective, the main character had to look great — if you spent 
the entire game looking at this character, it should be really nice 
to look at. We combined elements from the original H eavy M etal 
movie, the comics, and the new movie to create Julie. We went 
through three revisions of her character before finally settling on 
what you see in the game. 

When we designed the world, we wanted it to bean interactive 
version of the H eavy M etal universe. We decided to use a rich co- 
lor set with lots of red and yellows in the town, and we used vi- 
brant greens and blues for some of the outdoor areas. We wanted 
to get away from the dingy, dark look that so many other shoot- 
ers in the genre have. We put the Q uake 3 shader system to great 
use and were very liberal in our use of weapon effects and cine- 
matics. For our efforts, critics have proclaimed F.A.K.K. 2 to be 
one of the best-looking games of 2000. 

What Went Wrong 

INo project management. During the development of 
• F.A.K.K. 2, we had a project manager at the beginning of 
the project and a different project manager near the end. There 
were 12 months of development time in between, during which 
we had little to no management on the project. There were mem- 
bers of the team that took on this role, but only in a limited 
capacity, as they had tons of other work to do as well. 

N ot having a single person manage tasks, and letting just about 
every feature request get added to the list, was a major reason 




why we 
had to go 
into crunch 
mode in order 
to finish everything 
by our July dead- 
line. This resulted in 
a crunch mode that lasted 
nearly five months, and 
one month of "super 
crunch," consisting of 
seven-day weeks and 12- to 16- 
hour days. I don't mind crunch 
mode every now and then, but for 
an extended period of time it really 
wears you out. The team morale 
during this crunch was very low. 

We worked on never-ending task 
lists for months and months. J ust 
when you thought you were close to 
being done with what you were assign- 
ed, another 30 tasks would appear on 
the list after a team meeting where we 
would flesh out the incomplete areas of 
the design. H aving a good project man- 
ager allows you to have a majority of 
the design details fleshed out from the 
beginning, schedule the correct amount 
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of time for tasks, and have 
the appropriate number of 
people on the team to finish a 
game. This seems to be a 
major problem in the gaming 
industry, as nearly everyone I 
talk to has just about the same story 
about project management and 
death-march crunch modes. 

2 High team turnover rate on 
• a small team. At the begin- 
ning of this article, I mentioned that the 
team started off with 18 members, and 
we finished the game with 11. Of those 
11 people, only one person was on the 
original F.A.K.K. 2 team from the be- 
ginning. It was a weird project, be- 
cause most of the team didn't have a 




ABOVE. In-game 
screens hot of J ulie's 
house. 

LEFT. In-game 
screenshot of J ulie 
battling the Happy 
Mask Hourde 
creatures. 

BELOW. In- game mo- 
del of Gith Recruiter. 

handle on the 
design of the game. 
The key designers 
of gameplay had 
moved on, and 
weren't available to 
talk about the ideas 
that they had 
come up 
with. We 
ended up 
scrapping a 
lot of the original 
design document and 
starting over. This set 
us back pretty far in 
the gameplay area. 
Another area that suf- 
fered was models and 
animations. We lost sev- 
eral artists who worked 
on different animation 
packages, and when they 
left we had to redo the 
models they were 
responsible for. 



thi 

3. 



The gaming industry is a turbulent one; 
people join and leave companies on a reg- 
ular basis, and it definitely has an impact 
no matter what anyone says. Unless a 
person didn't contribute anything to the 
game, losing personnel greatly impacts 
finishing a game on time. F.A.K.K. 2 had 
a very small team that had to work extra 
hard to make up for the lost employees 
that weren't replaced. In the end though, 
we were very satisfied with the game's 
quality in spite of having lost so many 
people during the course of development. 

5 No multiplayer; a short game 
• for hardcore players. As I said, 
F.A.K.K. 2 was designed as a single-play- 
er game from the start. We were going to 
try to put multiplayer into the final re- 
lease if we had the time, but our J uly 
deadline came so quickly that we just 
didn't have the time to finish it. We also 
designed a very tight game that can be 
finished by hardcore game players in less 
than ten hours. 

This was our biggest complaint from 
reviewers and players alike. I do agree 
that the game is on the short side, but we 
didn't want to put in dozens of levels that 
repeated the same gameplay over and 
over, as so many other games do. Even 
though I am defending our decision in 
this article, I do acknowledge it as one of 
the problems that we had with the de- 
sign. A short game with no multiplayer 
has a very limited lifetime in the gaming 
industry. (N ote: As of the writing of this 
article, a multiplayer patch is in the 
works that will provide arena-style bat- 
tles in various F.A.K.K. 2 settings). 

4 No demo before release. Our 
• July deadline was fast approach- 
ing, and we had yet to release a playable 
demo to the Internet. This hurt us in two 
ways. First, we weren't able to build up 
any pre-game buzz by having a killer 
demo for our game, and when the game 
was released people seemed surprised to 
hear about it. Second, a lot of people will 
not buy a game unless they play a demo 
beforehand to see if they like it. 

Fortunately, we were able to get a demo 
out the door within two weeks of our re- 
lease, but the jury is still out on whether or 
not this is a good or bad thing. 



48 



d e c e m b e r 2000 I game developer 



(postmortem 




ABOVE. J ulie solving the puzzle of the Tiki Heads in the Swamp. 
BELOW. In- game model of the wise old Gruff. 

5 Complex systems. I mentioned this problem in the Sin 
• Postmortem back in M arch 1999, and it looks like it hit 
us again. It's not surprising, since we used many of the same sys- 
tems that we had in Sin, and we even extended them. Game de- 
sign on the PC is becoming more and more complex as time 
goes on. Level designers aren't just creating levels anymore. 
They have to design puzzles, scripted events, cinematics, and on 
and on. In F.A.K.K. 2 this is all done through the scripting lan- 
guage, so each level designer had to be something of a program- 
mer as well. On the artists' side, they also got a taste of pro- 
gramming. The effects system is driven entirely by text files, and 
the artists needed to learn the system's intricacies in order to get 
the effects they wanted. 

This complexity added more to the development time than we 
had anticipated. Even though everyone on the team was really fa- 
miliar with the engine, getting used to the new tools and modifica- 
tions took a lot of extra work. The scripts for F.A.K.K. 2 total near- 
ly 10,000 lines. I'm not really sure if this problem is ever going to 
change in the industry. As people demand ever more immersive 
game environments, the complexity goes up in order to 
attain these goals. 



In the End 




ven though F.A.K.K. 2 had its share of de- 
velopment problems, we are very proud 
of what we accomplished with the 
game. While the design of the 
game was not always as well de- 
fined as some of the team mem- 
bers would have liked, we still 
were able to create an incredibly 
fun third-person action game in just 
under 18 months. We feel that 
F.A.K.K. 2 is our best game to 
date, and our future games will 
only benefit from the experiences 
we had during its development, if 
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Mac Games: 

Interesting Times 




tt^^ ay you live in 

interesting 
I times" is a state- 
ment often attrib- 
uted to an ancient 
Chinese curse, and is a pretty accurate 
description of the M ac game market 
today. W hile there is ample opportunity for 
explosive growth on the M ac, there are also 
a few potential potholes for game develop- 
ers traveling down the Bondi-blue road. 

From a technical standpoint, the 
M acintosh platform is probably in the 
best shape it has ever been. A decent 
OpenGL implementation, a growing 
selection of 3D accelerators (ATI, 
3dfx, and potentially Nvidia), and 
some major game engines 
already ported (particularly 
Unreal Tournament and 
Q uake 3) form a strong foun 



dation for bringing top games to 
the M ac. The availability of cross- 
platform game engines is the single 
most important technology for M ac game 
developers. Developing a M ac version of an 
Unreal- or Quake 3-based game is consid- 
erably simpler that porting or co-developing 
a game with a proprietary engine. 

But in the middle of this rosy technical 
picture comes one of those "interesting" 
wrinkles: M acOSX. Apple's big push to 
build a truly modern OS presents game de- 
velopers with some difficult choices. While 
the technical advantages of S X are nu- 
merous (preemptive threads, protected 
memory, tighter OpenGL integration, bet- 
ter virtual memory, and so on), it also pres- 
ents a completely different code path for 
game developers compared to OS 8/9. And 
for the majority of developers who won't 
be able to ship S X -only games for quite 
a while, waiting for the consumer market 
to transition from OS 8/9 to X might be 
painful. Supporting two distinctly different 




Mac 

operating 
systems will 
require some hard 
work and lots of testing. After the transi- 
tion, when developers can target OS X 
exclusively, the M ac should be a technology 
platform on par with the best. 

The other half of the M ac gaming equa- 
tion is the state of the gaming market. For 
the past two years, Apple has aggressively 
(and successfully) jumped back into the 
consumer market with the iM ac. H owever, 
the market for M ac games has not grown at 
the same rate as the rest of the consumer 
M ac market. rdinarily this would be a 
problem publishers would love to have: a 
huge untapped group of potential game 
players just waiting for someone to sell 



them 
something. 
But selling to 
iM ac players has proven 
more difficult than expected. 
The M ac game market is a unique 
niche. M ac owners seem to be a bit older 
than their Windows counterparts, and 
somewhat more selective when buying 
games. Because many iM ac owners are 
first-time computer buyers, they may be 
less experienced about finding and pur- 
chasing new games. Games featuring a 
broad appeal and a low price may have 
more potential to sell to these novice 
gamers. And while it has been somewhat 
difficult to sell relatively hardcore games 
to iM ac users in the recent past, there is a 
good potential for an increase in iM ac 
players moving up to mid-range and high- 
continued on page 55 
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continued from page 56 
end titles. In fact, in the last few months, 
sales figures for the M ac versions of Th e 
Sims, Diablo II, and Deus Ex point to a 
potential breakthrough into this untapped 
user base. 

If this trend continues, M ac gaming can 
become a profitable area of growth for the 
game industry. H owever, the uniqueness of 
this market will still require specialized 
knowledge of distribution and marketing 
to promote good sales. Retail distribution 
on the M ac has been focused on only a 
few channels in the recent past (Comp- 
USA, for instance), so it has been impor- 
tant to take advantage of alternative chan- 
nels such as web sales and catalogs. This, 
in turn, makes it important to market cre- 
atively to M ac users and educate them on 
their most convenient points of purchase. 



Apple has been making strides in increas- 
ing the M ac's presence in traditional game 
retailers, like Electronics Boutique and 
Babbages, but the alternate means of dis- 
tribution still remain important. 

The final interesting twist impacting the 
M ac game market is not unique to the 
M ac. Just as Windows game developers 
are unsure of the potential effect of next- 
generation consoles like Playstation 2 and 
X box on their market, M ac game develop- 
ers are similarly concerned. If, as predicted 
by some, consoles capture a significant 
percentage of the PC game market, the 
M ac will also be impacted. 

Cross- platform development will be- 
come very important if the game industry 



becomes more fragmented due to the next- 
generation consoles. If market shares di- 
minish for individual platforms, producing 
games for multiple platforms will be a vi- 
tal way to maintain total revenue for a 
given title. J ust as in the early 1980s when 
the market was split between many com- 
peting platforms (Apple II, IBM PC, Com- 
modore 64, Atari), game developers pro- 
ducing original content may have to re- 
lease on as many operating systems as 
possible to recoup their investment. 

The M ac game market continues to 
have tremendous potential, and a few dif- 
ficult hurdles ahead. N o matter what the 
future brings, though, it will definitely be 
"interesting times." if 



M ark Adams | M ark is the president of Westlake I nteractive, and has been writing M ac 
games for 15 years. M ark can be reached at madams@westlakeinteractive.com. 
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